Perimeter security assumes that what is inside the network can be trusted, and once an attacker is inside, that assumption becomes the attacker's best asset. Zero trust removes network location as a reason to trust anything and moves decisions to the identity, device and resource in each request. This guide compares the two models in practical terms: which controls change, which stay, where each still has a role, and how a real organisation moves from one to the other while running both. It is for security architects, network leads and CISOs who need to explain the shift without the marketing, and it complements the NIST SP 800-207 Zero Trust Architecture Guide rather than repeating it.
Key takeaways
- The question changes from "where is it?" to "who and what is it?" NIST SP 800-207 states that no implicit trust is granted based on physical or network location or asset ownership; perimeter models grant exactly that.
- Zero trust keeps firewalls, it demotes them. Boundary controls remain useful for filtering and segmentation, but they stop being the decision that grants access to data.
- Identity becomes the control plane. Strong authentication, device trust and least-privilege authorisation for people and non-human identities carry the weight the perimeter used to carry.
- Every real organisation is hybrid. SP 800-207 expects most enterprises to operate in a mixed zero trust and perimeter mode for an extended period and to migrate one business process at a time.
- Success is measured in reduced implicit trust. Track flows allowed only by network location, coverage of phishing-resistant MFA and per-resource policy, not the number of zero trust products bought.
The two models in one paragraph each
Perimeter security (sometimes called castle and moat) concentrates defences at the boundary between a trusted internal network and untrusted external networks: firewalls, DMZs, intrusion prevention, VPN concentrators and web proxies. Inside, systems often talk freely, and access to internal applications is commonly granted to anyone with a network path and a password. NIST SP 800-207 section 1 notes the weakness directly: once attackers breach the perimeter, lateral movement is unhindered, and perimeter controls cannot protect remote workers or cloud services well.
Zero trust treats every network, including the internal one, as hostile. NIST SP 800-207 defines it through seven tenets, including that all communication is secured regardless of location, access is granted per session with least privilege, and access policy is dynamic, using identity, device state and behaviour. The NCSC's design principles put the same idea plainly as "Don't trust any network, including your own". Google's BeyondCorp paper (2014) described one of the first large implementations, moving corporate applications onto the internet behind user and device checks rather than a privileged intranet.
What actually changes in practice
| Area | Perimeter model | Zero trust model |
|---|---|---|
| Trust basis | Network location (inside equals trusted) | Verified identity, device health and request context, per session |
| Where decisions happen | Edge firewall and VPN concentrator | Policy engine and enforcement points close to each resource |
| Remote access | VPN onto the network | Per-application access (ZTNA, identity-aware proxy) |
| Internal traffic | Often unencrypted, broadly allowed | Encrypted and authenticated; OMB M-22-09 requires HTTPS for internal web and API traffic |
| Segmentation | Few large zones (DMZ, internal, management) | Macro and micro segmentation down to workloads; deny by default between them |
| Authentication | Once, at the edge; often password only inside | Strong, ideally phishing-resistant MFA, continuously re-evaluated |
| Device role | Mostly ignored once connected | Device identity and posture are policy inputs |
| Service-to-service | Trusted by IP allow lists and shared secrets | Workload identity (certificates, short-lived tokens) and mutual authentication |
| Monitoring | North-south traffic at the edge | Every access decision logged; east-west visibility |
| Failure mode | One breach of the edge exposes the interior | One compromised identity exposes only what its policy allows |
What stays the same
- Boundary filtering: internet-facing firewalls, DDoS protection and egress filtering still reduce noise and block known-bad traffic. NIST SP 800-53 SC-7 Boundary Protection applies in both models; zero trust adds more boundaries, it does not abolish them.
- Patching and hardening: zero trust does not make a vulnerable server safe. It limits who can reach it.
- Asset inventory: NCSC principle 1, "Know your architecture", and SP 800-207 section 7.3 both start with knowing users, devices, services and data. A perimeter programme needs this too; zero trust cannot work without it.
- Logging and response: SOC processes remain, with richer identity and decision logs to work from.
When perimeter controls still make sense
Zero trust is the direction of travel for most enterprise IT, but the perimeter has places where it remains the practical primary control.
| Situation | Reasonable approach | Notes |
|---|---|---|
| OT and industrial networks | Zones and conduits with strong boundaries | Many devices cannot authenticate per request; see the OT Network Segmentation, Purdue Model and IEC 62443 Zones and Conduits Guide |
| Legacy systems that cannot use modern authentication | Enclave gateway in front of the system (SP 800-207 enclave-based model) | A perimeter around a small group, not the whole estate |
| Payment card environments | Segmented CDE plus zero trust access into it | PCI DSS scoping still relies on segmentation; see the PCI DSS Scoping and Network Segmentation Guide |
| Small office with all applications in SaaS | Little internal network to protect; focus on identity and device | Zero trust in effect, without a "programme" |
| Greenfield cloud build | Design zero trust from the start | SP 800-207 section 7.1 notes a pure ZTA is most feasible for new builds |
Small organisations usually reach most zero trust outcomes by moving to SaaS, enforcing phishing-resistant MFA and device management, and removing the VPN. Large organisations need a programme with pillar owners, typically structured on the CISA Zero Trust Maturity Model (five pillars: Identity, Devices, Networks, Applications and Workloads, Data; with stages Traditional, Initial, Advanced and Optimal). See the CISA Zero Trust Maturity Model Guide.
Trade-offs
- Complexity moves, it does not vanish: fewer flat networks, many more policies. Without owners for each application policy, rules decay into broad allows.
- Identity provider as critical dependency: availability and integrity of the IdP and policy engine become business critical. Plan break-glass access and harden administrative roles.
- Legacy friction: applications that only support IP allow lists or NTLM need gateways or redesign. SP 800-207 notes migrating a workflow usually needs at least partial redesign.
- Cost profile: spending shifts from edge appliances to identity, device management, ZTNA or SSE subscriptions and logging volume.
- User experience: usually better (no VPN step), but step-up prompts and posture blocks need clear user messaging.
How to move from perimeter to zero trust
SP 800-207 section 7.3 lists the steps for introducing zero trust into a perimeter-based network. A practical sequence:
- Identify actors. Inventory human and non-human subjects, with extra scrutiny for administrators, developers and service accounts.
- Identify assets and flows. Inventory devices, applications and data, including shadow IT, and capture current traffic flows. Flow logs show which access depends purely on network location.
- Fix the identity foundation first. Phishing-resistant MFA for staff, removal of legacy authentication protocols, privileged access management for admins and an owner for every service account. OMB M-22-09 made phishing-resistant MFA a core requirement for US federal agencies.
- Choose a candidate process. Pick a business process with clear users and a bounded set of applications. SP 800-207 suggests low-risk processes are often a sensible start.
- Write and observe policy. Define access by identity group, device posture and resource; deploy in reporting-only mode to find gaps before enforcing.
- Enforce and segment. Turn on enforcement, then remove the network-level paths that the old model relied on (VPN routes, broad internal firewall allows).
- Expand and reassess. Repeat per process. Reassess the architecture when major changes such as acquisitions or cloud moves happen.
Testing and rollback: keep the old network path available but monitored for each migrated process during a fixed window. Rollback is restoring that path for the affected process only, recorded as a time-limited exception.
Each option in depth
For each option below: the threat it is built for, how it fails, the controls that make it work, when to choose it and a worked example.
Perimeter security
Threat model. The perimeter model assumes a trusted inside and an untrusted outside, separated by firewalls and remote access gateways. Its threat model is the external attacker. NIST SP 800-207 (August 2020) describes zero trust as moving defences "from static, network-based perimeters to focus on users, assets, and resources", which names exactly what the perimeter model misses: the attacker who is already inside, through a stolen credential on a remote access service (T1133, T1078), a compromised supplier or a phished user, and who then moves laterally (T1021).
Failure modes. Implicit trust by location, so one foothold reaches much of the network; flat internal networks; and internal traffic left unencrypted and unmonitored because it is "inside".
Controls. Keep boundary protection (SC-7) and information flow enforcement (AC-4), but add internal segmentation, encryption in transit (SC-8) and monitoring of east-west traffic.
Decision criteria. Perimeter controls remain right for OT zones, payment environments and legacy systems that cannot authenticate each request, provided segments are small and monitored.
Worked scenario. A plant network cannot run modern agents. The team keeps a firewalled zone and conduit, allows only named flows from a jump host, and monitors the conduit, accepting a perimeter for a small, well-defined segment.
Zero trust
Threat model. Zero trust assumes the network is hostile. NIST SP 800-207 states that no implicit trust is granted to assets or user accounts based solely on physical or network location, that authentication and authorisation of both subject and device are discrete functions performed before a session is established, and that the focus is protecting resources rather than network segments. Its threats shift to the policy engine, the identity provider and device signals.
Failure modes. Weak MFA presented as zero trust; a policy decision point that fails open; and machine identities left outside policy because projects scope users only.
Controls. Phishing-resistant MFA, per-resource policy (AC-3), device health checks, workload identity for services, and logging of every policy decision.
Decision criteria. Prioritise zero trust for internet-reachable applications, cloud workloads and high-value data, and where users and services work from anywhere.
Worked scenario. A finance application moves behind an identity-aware access layer. A phished password from a personal laptop fails the device check, and the policy log gives the SOC a clean record of the attempt.
Choosing the mix
Most estates run both models for years. A practical test is to ask, for each resource, whether a request can be authenticated and authorised per session. Where it can, move the resource behind per-request policy. Where it cannot, keep a small, monitored perimeter around it and record that decision with an owner and a review date, so the exception does not quietly become the architecture.
Where identity fits
Zero trust shifts the perimeter onto identities, including non-human ones. Service accounts, API keys, workload certificates and AI agents make most access requests in modern estates, and a perimeter model often trusts them by IP address alone. In a zero trust design each needs its own identity, least-privilege authorisation and short-lived credentials. The Change Healthcare breach shows the perimeter failure mode clearly: a remote access portal without MFA let attackers in, after which they moved laterally for days before deploying ransomware. See the Zero Trust for AI Agents Guide and the NIST SP 800-207A Zero Trust for Cloud-Native Applications Guide for workload identity.
Detection and measurement
- Log sources: policy engine decisions, IdP sign-ins with MFA method, device management compliance, east-west flow logs and firewall deny logs at segment boundaries.
- Detections that improve under zero trust: access attempts denied by policy, new device and identity combinations, service accounts used from unexpected workloads, and lateral connection attempts between segments that should never talk.
| Metric | What it shows |
|---|---|
| Internal flows allowed only by IP or subnet rule | Remaining implicit trust; should fall over time |
| Applications behind per-resource policy | Coverage of zero trust enforcement |
| Human sign-ins using phishing-resistant MFA | Strength of the identity foundation |
| Service accounts with an owner and credential rotation | Non-human identity readiness |
| Managed, compliant devices as a share of access requests | Device pillar maturity |
| CISA ZTMM stage per pillar | Programme progress in a board-friendly form |
Common failure patterns
- Rebranding the perimeter: buying a ZTNA product while leaving the flat internal network and broad VPN in place.
- Starting with network tools, not identity: microsegmentation projects stall when there is no reliable identity or asset inventory to write policy against.
- Weak MFA treated as zero trust: push approval and SMS remain phishable; the Cisco 2022 breach combined a synced password with MFA fatigue.
- Ignoring non-human identities: service-to-service traffic left on IP allow lists and long-lived shared secrets.
- Big bang plans: enterprise-wide cutovers instead of per-process migration, which stall when the first legacy dependency appears.
- No break-glass design: an IdP outage halts operations because every path now depends on it.
See Top 10 Zero Trust Mistakes for more.
Framework mapping
| Framework | Reference | Relevance |
|---|---|---|
| NIST SP 800-207 | Section 2.1 tenets; section 3.2 deployment models; section 7 migration | Defines zero trust and the hybrid path from perimeter |
| NIST SP 800-53 Rev. 5 | SC-7 Boundary Protection; SC-7(5) Deny by Default, Allow by Exception; AC-4 Information Flow Enforcement; AC-3 Access Enforcement; SC-8 Transmission Confidentiality and Integrity | Boundary controls (both models) and per-flow enforcement (zero trust) |
| NIST CSF 2.0 | PR.AA-05; PR.IR-01; PR.DS-02 | Least privilege, network protection, data-in-transit protection |
| CISA Zero Trust Maturity Model 2.0 | Five pillars and maturity stages | Programme structure and progress measurement |
| CIS Controls v8.1 | Control 3 Data Protection; Control 6 Access Control Management; Control 12 Network Infrastructure Management; Control 13 Network Monitoring and Defense | Segmentation, MFA, network monitoring |
| ISO/IEC 27001:2022 Annex A | A.5.15 Access control; A.8.20 Networks security; A.8.22 Segregation of networks | Access and network controls under either model |
| MITRE ATT&CK | T1078 Valid Accounts; T1021 Remote Services; T1133 External Remote Services | Techniques that exploit implicit internal trust |
Practitioner checklist
- List every access path that depends only on network location and assign an owner to remove it.
- Enforce phishing-resistant MFA for staff and remove legacy authentication protocols.
- Give every service account and workload an owner, an identity and a rotation plan.
- Keep boundary firewalls, and add deny-by-default segmentation inside.
- Migrate one business process at a time, observe policy before enforcing, then remove old paths.
- Encrypt and authenticate internal web and API traffic.
- Design and test break-glass access for IdP or policy engine outages.
- Report CISA ZTMM stage per pillar and the metrics above each quarter.
Standards and references
- NIST: SP 800-207 Zero Trust Architecture
- NCSC: Zero trust architecture design principles
- CISA: Zero Trust Maturity Model
- OMB: M-22-09 Moving the U.S. Government Toward Zero Trust Cybersecurity Principles
- NSA: Advancing Zero Trust Maturity Throughout the Network and Environment Pillar
- Google Research: BeyondCorp, A New Approach to Enterprise Security
- NIST: SP 800-53 Rev. 5
Related NHI Mgmt Group resources: ZTNA vs VPN · Network Segmentation Guide · NIST SP 1800-35 Implementing a Zero Trust Architecture Guide · Zero Trust Executive Briefing · Identity-Aware Proxy Guide