Zero trust might be the most abused term in cybersecurity. Every vendor slaps it on their marketing page. Every CISO puts it in their annual strategy deck. Every compliance framework references it. And yet, when you ask most organizations what their zero trust implementation actually looks like, you get a long pause followed by something about VPNs and multi-factor authentication.
That is not zero trust. That is the same old perimeter security with extra steps.
We are not a security company. CODERCOPS is a web development agency. But we build and deploy applications for clients who handle sensitive data -- fintech platforms, healthcare dashboards, e-commerce systems processing payment information. And over the past two years, the question "how do you secure this?" has shifted from "do you have a firewall?" to "what does your zero trust architecture look like?" Our clients are asking. Their auditors are asking. Their insurance providers are asking.
So we had to actually implement it. Not just talk about it. Here is what we found.
What Zero Trust Actually Means
The phrase "never trust, always verify" gets thrown around so much it has lost all meaning. Let me make it concrete.
In a traditional network security model, there is a perimeter. Everything inside the perimeter (your office network, your VPN, your internal servers) is trusted. Everything outside is not. Once you get past the perimeter -- through a VPN, through an office WiFi connection -- you are trusted to access internal resources.
The problem with this model is blindingly obvious in hindsight: if an attacker gets past the perimeter, they are trusted too. They can move laterally through your internal network, access any system that trusts "internal" traffic, and exfiltrate data while your perimeter security happily reports that nothing unusual is happening at the boundary.
This is exactly what happened in the SolarWinds attack. The attackers compromised a trusted software update mechanism, got inside the perimeter, and had free rein for months. The Change Healthcare breach followed a similar pattern -- compromised credentials gave attackers access to internal systems that assumed internal traffic was safe.
Zero trust flips this model entirely. No network location, no device, no user identity is inherently trusted. Every request -- whether it comes from the CEO's laptop in the office or a contractor's phone in a coffee shop -- must be authenticated, authorized, and encrypted. Every time.
Traditional Security Model:
[Internet] ---> [Firewall/VPN] ---> [Trusted Internal Network]
├── App Server (trusted)
├── Database (trusted)
└── Internal API (trusted)
Problem: Once inside, everything trusts everything.
Zero Trust Model:
[Any Network] ---> [Identity Verification] ---> [Policy Engine]
│
┌────────────┼────────────┐
▼ ▼ ▼
[App Server] [Database] [Internal API]
(verify each) (verify each) (verify each)
Every request verified. No implicit trust. No "inside."Traditional Perimeter vs. Zero Trust
| Aspect | Traditional Perimeter | Zero Trust |
|---|---|---|
| Trust model | Trust based on network location | No implicit trust, verify everything |
| Network access | VPN grants broad internal access | Access granted per-resource, per-session |
| Lateral movement | Easy once inside perimeter | Difficult -- every hop requires auth |
| Remote work | Requires VPN tunnel to "be inside" | No distinction between office and remote |
| Breach impact | Attacker has broad access once inside | Attacker limited to single compromised resource |
| User experience | VPN is slow and clunky | Transparent auth, often faster than VPN |
| Scalability | VPN concentrator becomes bottleneck | Distributed, scales with cloud |
| Visibility | Blind to internal traffic | Full logging of every access decision |
| Cloud compatibility | Poor -- designed for on-premise networks | Native -- designed for distributed systems |
| Compliance | Checkbox ("we have a firewall") | Substantive (continuous verification) |
The Five Pillars
Zero trust is not a single technology. It is an architecture built on five pillars, and you need all of them working together.
1. Identity
This is the foundation. If you don't know who is making a request, nothing else matters.
Every user and every service must have a verified identity. For humans, that means strong authentication -- MFA at minimum, ideally phishing-resistant methods like hardware security keys (FIDO2/WebAuthn) or passkeys. For services, that means machine identities -- certificates, tokens, or SPIFFE/SPIRE-based identity.
The shift that matters: identity is not just "did you log in?" It is continuous. Your session doesn't stay trusted just because you authenticated an hour ago. Behavioral signals (impossible travel, unusual access patterns, device fingerprint changes) can trigger re-authentication at any time.
We use Cloudflare Access for most of our client deployments. It sits in front of every internal application and verifies identity on every request. No VPN needed. The developer accessing the staging environment from Mumbai and the client checking their dashboard from New York go through the same identity verification flow.
2. Device
A verified user on a compromised device is still a threat. Zero trust requires knowing the state of the device making the request.
Is the OS patched? Is disk encryption enabled? Is the device managed by the organization or is it a personal phone? Is there endpoint detection running? These signals feed into the access decision. A fully patched, managed laptop might get access to production systems. A personal phone with an outdated OS might get read-only access to non-sensitive applications. A jailbroken device gets nothing.
This is where things get hard for small teams. Enterprise device management (MDM) solutions like Jamf, Intune, or Kandji are designed for large organizations with dedicated IT teams. For smaller teams, we have found that Tailscale's device identity features combined with basic device posture checks get you 80% of the value at 20% of the complexity.
3. Network
In zero trust, the network is hostile. All of it. Even your office WiFi. Even your cloud VPC.
This means all traffic is encrypted, all connections are authenticated, and network segmentation is granular. Instead of one flat network where everything can talk to everything, you create microsegments -- the web server can talk to the API server on port 443, the API server can talk to the database on port 5432, and nothing else is allowed.
Tailscale has become our go-to for zero trust networking. It creates a WireGuard-based mesh network where every device has a cryptographic identity and can only communicate with devices explicitly allowed in the ACL policy. There is no central gateway to bottleneck or compromise. Setting up a Tailscale network takes about 15 minutes, and the ACL policies are defined in a simple JSON file:
{
"acls": [
{
"action": "accept",
"src": ["group:developers"],
"dst": ["tag:staging:443", "tag:staging:22"]
},
{
"action": "accept",
"src": ["tag:api-server"],
"dst": ["tag:database:5432"]
},
{
"action": "accept",
"src": ["group:ops"],
"dst": ["tag:production:*"]
}
],
"groups": {
"group:developers": ["alice@company.com", "bob@company.com"],
"group:ops": ["carol@company.com"]
},
"tagOwners": {
"tag:staging": ["group:developers"],
"tag:production": ["group:ops"],
"tag:database": ["group:ops"],
"tag:api-server": ["group:ops"]
}
}Developers can reach staging servers on ports 443 and 22. The API server can reach the database on 5432. Ops can reach everything in production. Nobody else can reach anything. And this policy is version-controlled and auditable.
4. Application
Every application should authenticate and authorize every request, regardless of where that request comes from. This is where most developers actually interact with zero trust.
It means your API doesn't trust requests just because they came from an "internal" IP. It validates the JWT, checks the permissions, verifies the scope, and logs the access decision. It means your admin panel doesn't rely on network-level access control ("only accessible from the VPN") as its sole security layer. It has its own authentication and authorization, even if the network layer is also restricting access.
Defense in depth. If the network layer fails, the application layer catches it. If the application layer has a bug, the network layer limits the blast radius.
5. Data
The ultimate goal of zero trust is protecting data, not networks or applications. Data should be classified (what is sensitive, what isn't), encrypted (at rest and in transit), and access-controlled (who can read what, who can write what, under what conditions).
This is the pillar most organizations handle worst. They get identity right, network mostly right, and then the database has a single set of credentials that gives read-write access to everything. Or the S3 bucket has overly broad IAM policies because getting the permissions right was "too complex."
We use HashiCorp Vault for secrets management on larger client projects. Dynamic database credentials (Vault generates short-lived credentials for each session), automatic rotation, and a full audit log of every secret access. For smaller projects, Doppler or even Vercel's encrypted environment variables are adequate -- the point is that secrets are centrally managed and auditable, not scattered across config files and Slack messages.
The Hardest Part Nobody Talks About
The technology is the easy part. Seriously. Cloudflare Access, Tailscale, Vault -- these tools work. You can set them up in a week. The hard part is everything else.
Legacy Systems
Every organization has that one system. The 2012 Java app that runs a critical business process. The Windows Server 2012 box that hosts the ERP. The internal tool that authenticates via IP whitelist and has no concept of OAuth or JWT.
These systems cannot participate in a zero trust architecture natively. You cannot just "add MFA" to a 14-year-old application that authenticates against an LDAP directory. The options are: put a zero trust proxy in front of it (Cloudflare Access, Pomerium, or similar), wrap it in a gateway that handles authentication and passes through requests, or isolate it in its own microsegment with strict access controls and plan for replacement.
All three options are compromises. None are clean. This is the messy reality of zero trust implementation that the vendor marketing never shows you.
Cultural Resistance
"But we've always had VPN." This sentence has cost us weeks of project time.
Developers and employees are used to VPN. They understand VPN. "Connect to VPN, access stuff" is a mental model that has been ingrained for decades. Replacing it with "every application authenticates you individually based on your identity and device posture" feels like more friction, even when it is actually less.
We have found that the best way to handle this is to start with the applications people use most -- the ones where VPN is already annoying. Show them they can access the staging environment from their home WiFi without connecting to VPN first. Let them experience the improvement. Then expand.
The Vendor Landscape Is Confusing
"Zero trust washing" is real. Vendors rename existing products, add "zero trust" to the marketing, and call it a day. A traditional firewall vendor will sell you a "zero trust firewall." A VPN vendor will sell you a "zero trust VPN." These are contradictions in terms, and they make it genuinely hard for non-specialists to evaluate solutions.
Our rule of thumb: if a vendor says "buy our product and you have zero trust," they are lying. Zero trust is an architecture, not a product. Products implement pieces of it. You need to understand the architecture first and then select products that fill specific roles.
Zero Trust for Small and Medium Companies
You do not need a million-dollar budget. Here is what a realistic zero trust implementation looks like for a team of 5-50 people:
Start with identity (week 1). Enforce MFA on everything. Google Workspace or Microsoft 365 with enforced FIDO2/passkey MFA for all users. This single change eliminates the most common attack vector -- compromised passwords.
Add zero trust access to applications (weeks 2-3). Put Cloudflare Access (free for up to 50 users) or Tailscale (free for up to 100 devices) in front of your internal applications. Remove VPN access and replace it with per-application authentication.
Implement secrets management (week 4). Move credentials out of config files, environment variables, and Slack messages into a secrets manager. Doppler has a generous free tier. HashiCorp Vault if you need more control. Rotate all credentials that have been shared in plaintext.
Enable logging and monitoring (ongoing). Every access decision should be logged. Cloudflare Access and Tailscale both provide audit logs out of the box. Review them weekly. Look for anomalies -- access from unexpected locations, unusual hours, repeated failed attempts.
Total cost for a 20-person team: roughly $0-200/month using free tiers of Cloudflare Access and Tailscale, plus a secrets manager. The ROI compared to a single breach -- which costs small businesses an average of $149,000 according to IBM's 2025 Cost of a Data Breach report -- is enormous.
Common Mistakes
Treating zero trust as a project with an end date. It is a continuous posture, not a one-time implementation. Threats evolve. Your architecture needs to evolve with them.
Ignoring service-to-service authentication. Teams focus on human user authentication and forget that services also need identity. Your API calling another internal API should authenticate that call, not rely on network-level trust.
Making it so restrictive that people work around it. If your zero trust implementation makes it take 45 minutes to access a staging environment, developers will find workarounds. And those workarounds will be less secure than what you replaced. Balance security with usability.
Buying a "zero trust platform" without understanding the architecture. You need to know what you are trying to achieve before you select tools. Otherwise, you are spending money on a vendor's interpretation of zero trust, which may not match your actual risk profile.
Not testing. Schedule regular access reviews. Try to access resources you shouldn't be able to reach. Verify that terminated employees actually lose access. Test the assumption that the policies work as written.
What to Do This Week
If zero trust feels overwhelming, start here. These five things take less than a day total and measurably improve your security posture:
Audit who has access to what. List every tool, service, and system your team uses. Check who has access. Remove access for anyone who doesn't need it. This takes two hours and always turns up surprises.
Enable MFA on your most critical accounts. Email, source control, cloud provider, domain registrar. If any of these lack MFA, fix it today. Use hardware keys for admin accounts if possible.
Check your VPN configuration. If your VPN gives every connected user access to every internal resource, that is the definition of implicit trust. Start planning per-application access controls.
Review your secrets. Search your git history for accidentally committed credentials (use TruffleHog or GitLeaks). Check Slack history for passwords shared in plaintext. Rotate anything you find.
Document your access policies. Write down who should have access to what and why. This document becomes the foundation for your zero trust policy. If it doesn't exist, your access control is ad-hoc, which means it is wrong.
Zero trust is not a destination. It is a direction. You don't wake up one morning and declare your organization "zero trust compliant." You make incremental improvements -- each one reducing the blast radius of a potential breach, each one making lateral movement harder for an attacker, each one giving you better visibility into what is happening in your systems.
The perimeter model served us well for decades. But it was built for a world where your employees sat in an office, your servers lived in a closet, and "the internet" was something outside your walls. That world is gone. Your employees work from everywhere. Your infrastructure spans multiple clouds. Your applications are accessed from devices you don't control.
The only rational response is to stop trusting the network and start verifying every request. That is zero trust. And in 2026, it is not optional anymore.
Comments