For a long time, company security worked like an old office building. Getting past reception was hard. But once you were in, you could wander anywhere: any floor, any meeting room, any unlocked filing cabinet. Being inside was the permission.

Networks were built the same way. A firewall at the edge, a VPN to get in, and inside, everything trusted everything. The admin panel only checked that you came from an internal IP address. The database accepted connections from anything on the same network.

Zero trust is the idea that this was always a bad deal. It's become a buzzword that vendors stick on everything, but the core idea is simple and, honestly, a bit obvious once you hear it.

The one-sentence version

Never trust a request because of where it comes from. Check who is making it, from what device, and whether they should be allowed to do this specific thing, every time.

A better analogy than the office is a modern hotel. Your key card opens your room and the gym. Not other rooms, not the kitchen, not the server cupboard. It stops working when you check out. And the hotel can cancel it instantly if you lose it. Being inside the hotel gives you nothing by itself.

Why the castle-and-moat model stopped working

• There's no "inside" anymore. People work from home, cafés and phones. Apps run in AWS, email is a SaaS product, files live in cloud storage. The perimeter has holes everywhere by design.
• Attackers get in eventually. One phishing email, one reused password, one unpatched laptop. Once they're inside a flat, trusting network, they move sideways to everything else. That "lateral movement" is what turns a small breach into a big one.
• Insiders and mistakes exist. Not every risk is a hooded hacker. Over-broad access turns an honest mistake into an incident.

The US standards body NIST describes zero trust architecture in its publication SP 800-207, and Google's BeyondCorp work is the best-known early example of a company moving its staff off the VPN model. You don't need to read either to apply the idea, but they're a sign this isn't just marketing.

The principles, in plain words

1. Verify explicitly

Every request is authenticated and authorised, based on identity and context, not network location. Strong sign-in is the foundation: single sign-on so there's one place to control access, and multi-factor authentication. Phishing-resistant methods like passkeys and security keys are the gold standard, because a code from an SMS can be phished and a passkey can't be used on a fake site.

2. Least privilege

Everyone (and every service) gets the minimum access needed, for the minimum time. The finance team gets the finance app, not the whole network. Admin rights are granted when needed and expire, rather than living permanently on someone's everyday account.

3. Assume breach

Design as if an attacker is already inside, and limit what they can reach. Segment networks and systems so one compromised laptop or server can't talk to everything. Encrypt traffic even between internal services. Log access so you can see what happened.

4. Check the device, not just the person

A valid password typed on an unpatched, unmanaged laptop is a risk. Mature zero trust setups check device health before granting access: is it a company device, is the disk encrypted, is the OS up to date?

What it means for developers

Zero trust isn't only an IT department project. A lot of it lives in the code we write:

• Don't use the network as your auth. "This endpoint is internal, so it doesn't need authentication" is the castle model in a single line. If an attacker lands on any internal machine, that endpoint is theirs. IP allow-lists can be a useful extra layer, never the only one.
• Services should prove who they are to each other. Service-to-service calls should carry credentials (scoped tokens, signed requests, or mutual TLS), and each service should check them.
• Give each app its own, smallest credentials. A reporting service needs read access to some tables, not the root database user. In AWS, that means IAM roles scoped to what each workload actually does, not one all-powerful key shared everywhere.
• Authorise every action, not just the login. Being signed in proves who you are. It doesn't prove you can view this contract or approve this payment. Check permissions on each request (in Laravel, policies and gates exist for exactly this).
• Keep sessions and tokens short-lived and revocable, so access can actually be taken away.
• Log access to sensitive data, with enough detail to answer "who looked at this, and when?"

Three myths worth dropping

Myth: zero trust is a product you buy. Vendors sell components (identity providers, device management, secure access gateways), but zero trust is an approach. You can't install it, any more than you can install "good code".

Myth: zero trust means we don't trust our people. It's not about suspicion. It's about not giving every account the power to cause a disaster if it's stolen. Your colleagues' passwords can be phished however trustworthy they are.

Myth: it's all or nothing. Nobody flips a switch. It's a direction you move in, one improvement at a time.

Where a small team can start

You don't need an enterprise budget to move in this direction. A practical order:

1. Single sign-on for the main business apps, and MFA everywhere, starting with admin and email accounts.
2. Remove shared accounts and standing admin rights. Named accounts, elevated only when needed.
3. Review who can access what, and remove what isn't needed. Do it again every few months, and when people change roles or leave.
4. Put authentication in front of every internal tool, including the ones "only reachable from the office".
5. Manage and patch company devices, with disk encryption turned on.
6. Segment the network so guest Wi-Fi, office devices and servers can't freely reach each other.

Each step makes a stolen password or an infected laptop less catastrophic. That's really all zero trust promises: not that nothing will ever go wrong, but that when it does, the damage stays small.

Which "internal only" endpoint or shared admin account would you fix first if you started on this tomorrow? Most of us have at least one.