The traditional network security model was built around a perimeter. Put your important stuff inside the castle walls, verify identity at the gate, and trust everyone inside. This made sense when "inside" meant a physical data center and your employees sat at desks on a corporate LAN. It makes much less sense when your infrastructure lives in AWS, your employees work from cafes and home offices, and your SaaS applications are all outside the perimeter anyway.
Zero trust is the name for the architectural philosophy that replaces the perimeter model. The core principle is simple: don't trust any request based solely on its network location. A request coming from inside your corporate network is not inherently more trustworthy than a request coming from the internet. Verify identity continuously, grant minimum necessary access, and assume that any given system or credential may already be compromised.
This isn't a product you buy. It's an architectural approach composed of several distinct practices that work together. The vendor ecosystem has responded to the popularity of the term by slapping "zero trust" on everything from VPNs to firewalls, which has made it genuinely hard to understand what you're actually implementing.
Why VPNs Alone Don't Get You There
VPNs solve a specific problem: encrypting traffic between a remote endpoint and a network. They don't provide zero trust because they rely on the perimeter model - once you're connected to the VPN, you're "inside" and you get broad network access. If an attacker compromises a user's credentials and connects via VPN, or if a user's device is already infected when they connect, they get the same access as a legitimate user.
More importantly, VPN connections are typically static grants of access. An engineer who needs to access a specific database server connects to the VPN and gets access to the entire subnet - including dozens of other systems they have no business need to reach. That's not least-privilege access. It's legacy network segmentation with encryption on top.
The Three Core Practices
Multi-factor authentication is the most basic zero trust building block. Every system, every user, every service account. Not just production systems - also your admin panels, your internal tools, your cloud provider console. TOTP apps (Authenticator, Authy) are better than SMS. Hardware keys (YubiKey) are better than TOTP apps. The specific mechanism matters less than universal adoption. An organization where MFA is inconsistently applied has large gaps that attackers will find.
Least-privilege access means users and systems get exactly the permissions they need for their current task, and no more. This is a principle that most organizations pay lip service to and almost none fully implement. The typical state of a five-year-old AWS organization is dozens of IAM roles with wildcard permissions that were created because it was faster, and service accounts with admin access because nobody wanted to debug the permission error. Cleaning this up is unglamorous work - but it's one of the highest-ROI security investments you can make.
Microsegmentation is the network-layer expression of least privilege. Instead of allowing free communication between everything inside your perimeter, you define explicit rules about which services can talk to which other services. In Kubernetes, this is implemented via Network Policies. In AWS, it's security group rules and VPC segmentation. The goal is to ensure that if an attacker compromises one service, they can't use that foothold to freely reach other services that the compromised service has no legitimate reason to communicate with.
Continuous Verification in Practice
"Always verify" means more than checking credentials at login. It means checking the health and posture of the device making the request, verifying that access patterns match historical norms, and re-authenticating for sensitive operations rather than relying on a session established hours earlier. This is what technologies like BeyondCorp (Google's internal implementation, now available commercially as BeyondCorp Enterprise) and Cloudflare Access implement.
Device trust is part of continuous verification that smaller organizations often skip. Is the device making this request enrolled in your MDM? Does it have an up-to-date OS? Is the disk encrypted? A user with valid credentials connecting from an unmanaged personal device presents meaningfully different risk than the same user connecting from a managed corporate device.
A Realistic Implementation Path for 50 People
You don't build zero trust in a weekend, and you don't need a million-dollar budget. Here's a sequenced approach that most 50-person companies can execute.
Start with identity. Get everyone using a proper identity provider - Okta, Google Workspace, or Microsoft Entra. Enforce MFA universally. Set up SSO for all your major SaaS tools so that when an employee is offboarded, revoking their identity provider account immediately revokes access everywhere. This alone closes a massive percentage of the access control gaps that most small companies have.
Then tackle your cloud permissions. Run an IAM access review in AWS, GCP, or Azure. Start with your most sensitive resources - production databases, secrets managers, billing - and remove any permissions that aren't specifically required. A role that only reads from DynamoDB should not have DynamoDB full access. This review is painful but achievable in a focused week.
Then set up network segmentation for your most sensitive services. If your payment service and your analytics service are running in the same network with no access controls between them, that needs to change. Define explicit ingress and egress rules. Treat service-to-service authentication the same way you treat user authentication - explicitly grant, explicitly revoke.
After that foundation is in place, you can start adding layers - device trust checks for remote access, anomaly detection for access patterns, application-level access proxies. But the identity and permissions work gives you most of the benefit, and it's achievable without a dedicated security team.
Zero trust isn't a destination. It's a direction. The goal isn't to implement every possible verification mechanism - it's to progressively reduce how much you rely on implied trust, so that the blast radius of any individual compromise is as small as possible. For a 50-person company, three months of focused work gets you to a meaningfully better state than most companies ten times your size.