Most organizations already own the familiar kit: a firewall at the edge, a VPN for remote workers, badges on the doors, and a security team watching the boundary. That approach is called perimeter security, and for a long time it matched reality. Offices were offices. Servers sat in a room down the hall. The people who needed access were, mostly, sitting inside the building.

None of that is reliably true now, and the mismatch causes real problems. The useful question is not whether zero trust sounds better. It is whether your security model still fits how the business runs — and if not, what to change first without stalling everything else.

What perimeter security assumes

The core assumption is simple: inside is trusted, outside is not. Cross the boundary with the right credentials and you are treated as a friend. Firewalls, VPN concentrators, and internal network ranges all follow that logic.

Picture a contractor who updates a spreadsheet once a week. Under a classic VPN setup, they connect to the corporate network and land on a subnet. The spreadsheet is there — but so is the file server, the intranet, and probably a few administrative tools. Nothing malicious happened. The design simply handed over more reach than the job required.

That is not a story about careless engineers. The perimeter was a sensible fit for data centers run by the same people who issued the laptops. Its weakness appears when the boundary blurs: cloud applications, personal devices, partners, and staff working from kitchens and airports.

How zero trust answers a different question

Zero trust drops the assumption that location equals safety. Instead of asking "is this request coming from inside?", it asks several questions for every request: who is asking, on what device, in what state, to reach which resource, and does policy allow it right now?

Trust becomes a decision made per session rather than a status granted once. Three principles do most of the work:

• Verify explicitly. Base access on identity, device health, and context signals — not network address.
• Grant least privilege. Give access to one application, not a subnet, and time-box it where you can.
• Assume breach. Design so a compromised laptop or server cannot quietly reach everything else.

None of that requires buying a product with "zero trust" on the box. It requires changing where access decisions are made.

What it looks like in practice

The day-to-day differences are less exotic than the terminology suggests:

• Remote access to one application through an identity-aware proxy, instead of a tunnel into a whole network.
• A device check before the connection opens: operating system patched, disk encrypted, endpoint agent reporting.
• Multi-factor authentication on email, admin consoles, and anything holding customer data.
• Segmentation inside the data center, so one compromised server cannot scan the estate.
• Logs that tie a person, a device, and a resource to a single session you can review later.

The trade-offs worth naming

Zero trust costs money and attention. Policy engines and agents carry license fees, identity work consumes staff time, and users notice when access changes. Legacy applications that only understand IP allowlists will resist you, and a rushed rollout interrupts work in visible ways.

Perimeter security, once running, is cheap and well understood. That matters. The honest framing is not "replace the perimeter" but "stop depending on the perimeter as your main authorization decision."

Where perimeter controls still earn their keep

Firewalls, egress filtering, network segmentation, and physical access control all remain useful. Zero trust does not mean having no boundary; it means treating the boundary as one input among several rather than the deciding factor. A firewall still absorbs a great deal of noise, and a badge reader still keeps unauthorized people out of the server room.

A perimeter is not a wall you demolish. It is one signal in a decision you make every time someone asks for something.

Signals that a shift makes business sense

Zero trust is a direction, not a switch. These signs usually justify starting a phased move:

• Remote and hybrid work is permanent, and remote access leans on one overloaded VPN.
• Core processes run in SaaS and cloud infrastructure your network boundary does not protect.
• Contractors, vendors, or partners need specific systems, and you are granting more than they need.
• An incident or near-miss revealed lateral movement you could not see at the time.
• Customer, insurer, or regulator questionnaires now ask about least privilege, MFA, and segmentation.

If two or three of those are true, a phased programme is reasonable. If none are, you will likely get more value from unglamorous basics: asset inventory, patching, tested backups, and MFA on email and administrator accounts.

A migration path that does not stall

1. Inventory what matters. List the data and applications that would hurt to lose, and who genuinely needs each one.
2. Fix identity first. Single sign-on, MFA, and a clean process for joiners, movers, and leavers. Most of the value sits here.
3. Pick one application. Move a single high-value service off broad network access, then measure the disruption.
4. Add device checks in stages. Report first, enforce second, tighten third.
5. Segment the flat spots. Start with the systems that would cause the most damage if reached.
6. Log, then review. Read denied requests weekly for a quarter; they reveal policy that is too loose or too tight.
7. Retire what you replaced. Old VPN rules and firewall exceptions become quiet holes. Close them deliberately.

How to decide this quarter

Ask three questions. What is the worst realistic outcome if an attacker takes over one employee laptop? How many systems could they reach from there? What would it cost to cut that number in half?

If the second answer is "most of them," you do not need a grand programme to begin. Put your most sensitive application behind single sign-on, require a managed device to reach it, and log every session. Then repeat with the next application. Write down what success looks like in twelve months — share of applications behind SSO, VPN sessions retired, unmanaged devices with access to anything important — and fund the work in yearly slices rather than one heroic project. If the scope spans several business units, have an independent assessor review the design before the first rollout; a second opinion is cheaper than a second incident.

Photo: Michael_Pointner / Pixabay