What Is Zero Trust: Architecture, Principles, and Practical Implementation

Zero Trust is a security model that eliminates implicit trust based on network location and requires continuous verification of every access to resources, regardless of whether the request originates inside or outside the corporate perimeter. The reference publication is NIST SP 800-207 (Zero Trust Architecture), complemented by the CISA Zero Trust Maturity Model v2 and earlier work from Google (BeyondCorp) and Forrester (the original model by John Kindervag, 2010). The central premise is captured in the phrase never trust, always verify: no user, device, application, or traffic flow is granted access simply because it sits inside an "internal" segment.

Zero Trust at a glance

• It is an architectural strategy, not a product you can buy off the shelf.
• It replaces the network perimeter with dynamic per-session policies based on identity, device, and context.
• It builds on existing components (IdP, MFA, EDR, microsegmentation, SIEM) coordinated by a central policy engine.
• A realistic implementation is gradual, spanning 12 to 18 months, prioritising identity and device before application and data.
• It maps to NIS2 article 21, the Spanish ENS (Royal Decree 311/2022), DORA chapter II, and ISO 27001:2022, covering access control, segmentation, and continuous monitoring.

Why the traditional perimeter stopped working

For two decades enterprise security relied on a geographic idea: everything inside the firewall is trusted, everything outside is hostile. That model worked when employees were in the office, servers lived in a private data centre, and critical applications were exposed at most through a DMZ. Today's reality has dismantled the four assumptions that sustained the perimeter.

The cloud has dissolved the data centre. Critical data lives in SaaS (Microsoft 365, Salesforce, Workday) and IaaS (AWS, Azure, GCP) that you do not control at the network layer. The perimeter firewall does not see the traffic between a user and the CRM API. Mobility and BYOD mean that legitimate devices connect from home networks, coffee shops, and 5G networks beyond corporate control. Software supply chain attacks inject third-party code into your core, as recent incidents in widely deployed components have shown. And post-breach lateral movement has become the norm: once inside, an attacker walks the internal network because the internal network was trusted by default.

Zero Trust answers these four pressures coherently: stop defining security by where the resource lives and start defining it by who is accessing it, with what device, to which specific resource, and in what context.

The principles of Zero Trust according to NIST 800-207

NIST SP 800-207 lists seven tenets that every Zero Trust architecture must respect. They are not optional and you cannot meet them halfway: each one has concrete design implications.

1. All data sources and computing services are considered resources. Previously only application servers were protected. In Zero Trust, a corporate printer, a code repository, an IoT endpoint, or a serverless function are resources with their own access policies. Practical example: a meeting-room IP camera has a policy that allows outbound traffic only to its cloud manager and denies any inbound connection from the internal network.

2. All communication is secured regardless of network segment. Internal traffic is not assumed to be safe. mTLS between microservices, TLS 1.3 for client-server traffic, and token signing on every API call are the norm, even on "private" networks.

3. Access to individual resources is granted on a per-session basis. Sessions are atomic: a user who authenticates to read email does not automatically gain access to the ERP. Each resource requires its own policy evaluation. This breaks the classic VPN model that drops the user into a flat network after authentication.

4. Access is determined by dynamic policy. The policy combines subject identity (user, service), device state (patches, EDR enabled, disk encryption), resource attributes (data classification), context (time, location, behavioural anomalies), and external signals (threat intelligence, malicious IP lists). Example: a user with MFA but a laptop missing recent patches can only access low-risk applications.

5. The enterprise monitors and measures the integrity and security posture of all owned and associated assets. It is not enough to verify at session start. If the device changes state during the session (EDR is disabled, it connects to a suspicious network), the policy re-evaluates and may revoke access.

6. All resource authentication and authorisation are dynamic and strictly enforced before access is allowed. Phishing-resistant MFA (FIDO2, hardware keys), token validation at every hop, OAuth scope checks on every call.

7. The enterprise collects as much information as possible about the current state of assets, network infrastructure, and communications, and uses it to improve its security posture. Continuous telemetry into SIEM and UEBA. Detection is not an add-on module, it is the fuel that feeds the policy engine.

Components of a Zero Trust architecture

NIST defines a logical core of three components that every Zero Trust implementation orchestrates, plus a series of supporting subsystems that supply the signals needed to make decisions.

Decision core: PE, PA, PEP

• Policy Engine (PE): the brain. It receives the request, evaluates the policy against all available signals (identity, device, risk, context), and issues a decision to grant, deny, or require additional steps.
• Policy Administrator (PA): the executor. It translates the PE decision into a concrete session (issues tokens, sets up tunnels, programs rules at the PEP).
• Policy Enforcement Point (PEP): the place where policy is enforced against real traffic. It can be a ZTNA proxy, a microservice sidecar, an endpoint agent, an identity broker, or a combination.

Supporting subsystems

• Identity Provider (IdP) with MFA and adaptive authentication: identity is the primary control plane. Without a strong IdP (Entra ID, Okta, Ping, Auth0, Keycloak) and phishing-resistant MFA, the rest of the model collapses.
• Device trust and posture: MDM (Intune, Jamf, Kandji), EDR (CrowdStrike, SentinelOne, Microsoft Defender, ESET), and compliance agents that emit real-time signals about device state.
• Microsegmentation: at the network layer (VLAN, SDN), at the workload layer (L7 policies between workloads), and at the application layer (mTLS between services). Reduces blast radius when something is compromised.
• SASE / SSE: convergence of network and security capabilities into a cloud platform. SASE adds SD-WAN, SSE is the security-focused subset (SWG, CASB, ZTNA, DLP, FWaaS).
• Continuous monitoring: SIEM (Splunk, Sentinel, Elastic, Wazuh) and UEBA for behavioural anomaly detection. Feeds back into the policy engine.
• Data security: classification, DLP, encryption, and key management. Without knowing what data you hold, you cannot protect the right resources.

ZTNA vs traditional VPN

ZTNA (Zero Trust Network Access) is the component that, in many organisations, progressively replaces the VPN as the gateway for remote access. The difference is not cosmetic.

When to migrate from VPN to ZTNA: when most access is to web applications or APIs, when you want to reduce the blast radius of contractor access, when you tackle a SASE/SSE project.

When to coexist: legacy applications that require protocols not easily proxied (some heavy database clients, industrial systems with real-time protocols), low-level administration of on-premise infrastructure, early migration phases where not everything is ready to publish via ZTNA.

Realistic implementation phases (12 to 18 months)

One of the most common traps is to approach Zero Trust as a monolithic project. A realistic implementation is gradual, organised by control domain, and prioritises quick wins.

Phase 0: baseline (weeks 1 to 4)

Up-to-date inventory of users, devices, applications, and data flows. Map of privileged identities. Diagnosis against the CISA Zero Trust Maturity Model. Definition of the target state at 12 and 24 months. Without this, any technical decision is built on assumptions.

Phase 1: identity (months 1 to 4)

The highest return phase. Consolidation on a single IdP, deployment of phishing-resistant MFA (FIDO2) across all access, removal of shared accounts, separation of privileged accounts, risk-based adaptive authentication, SSO integration for key SaaS applications. Typical quick win: blocking legacy authentication protocols in Microsoft 365.

Phase 2: device (months 3 to 6)

Enrolment of all endpoints in MDM, deployment of modern EDR, definition of device posture (disk encryption, patches, EDR enabled, no jailbreak). Integration of the posture signal into the IdP to condition access. Common trap: forgetting non-corporate devices (executive BYOD, contractors) that end up being the hole.

Phase 3: application (months 5 to 10)

Publishing internal applications via ZTNA instead of VPN. Mandatory SSO for SaaS. Review of OAuth permissions granted to third-party applications. Start of microsegmentation between critical workloads. Quick win: retire VPN for 70 percent of use cases, leaving a residual niche.

Phase 4: data (months 8 to 14)

Classification of critical data. DLP in email, endpoints, and SaaS. Encryption at rest with controlled key management. Information labelling (Microsoft Purview, equivalents) integrated with access policies. The longest phase, because it requires discovering what sensitive information actually exists.

Phase 5: monitoring and response (continuous, intensifies months 10 to 18)

SIEM with Zero Trust specific use cases (off-pattern access, privilege escalation, posture anomalies). UEBA. Integration with SOAR for automated responses (session revocation, endpoint isolation). Purple team exercises to validate detection.

Common traps: treating Zero Trust as a single-team project (it is cross-functional), buying a "Zero Trust" product before doing phase 0, ignoring the cultural change (users will see more initial friction), forgetting legacy applications in planning.

High-ROI use cases

Not every Zero Trust initiative returns the same value. These are the cases where the cost-benefit is clearest in the short term.

Remote access for contractors and third parties. The highest typical return. Publishing specific applications via ZTNA instead of issuing VPN to every contractor drastically reduces the surface and simplifies rotation. Auditable per session.

Protecting crown jewels (PII, intellectual property, regulated data). Isolating applications that handle critical data behind strict Zero Trust policies, with reinforced MFA, managed-device restrictions, and detailed logging. It is also a defensible argument before DPOs and regulators.

Reducing surface after M&A. After a merger or acquisition, integrating networks is slow and risky. Publishing the acquired entity's key applications via ZTNA enables controlled access from day one without opening network tunnels between the two organisations.

NIS2 and ENS compliance. Both regulations require access control, segmentation, and continuous monitoring. Zero Trust is not mentioned literally in the text, but the controls they demand map directly onto the architecture.

Alignment with NIS2, ENS, DORA, and ISO 27001

Zero Trust is not a named regulatory requirement, but the controls it materialises are exactly what the main European regulations and international standards demand.

For audit preparation, see the NIS2 audit step-by-step guide and the ISO 27001 complete guide.

Vendor landscape 2026

The Zero Trust ecosystem in 2026 is populated by vendors that cover different angles. This section describes technical capabilities without commercial endorsement: the choice depends on the starting point, the existing stack, and the priorities.

• Zscaler ZPA: pioneer in pure ZTNA, focused on application publishing and large-scale SSE. Good fit when the priority is retiring VPN and a specialised vendor is preferred.
• Palo Alto Prisma Access: complete SASE leveraging the vendor's NGFW heritage. Traction in organisations that already run Palo Alto at the perimeter.
• Cloudflare Zero Trust: own global network, integrated ZTNA, SWG, CASB, and public application protection. Fast adoption curve, strong in cloud-first organisations.
• Microsoft Entra (formerly Azure AD) + Entra Internet Access / Private Access: native integration advantage for Microsoft 365 environments. The Microsoft network access offering has matured quickly.
• Cisco Duo: focus on MFA and device trust, historically the identity piece many organisations add first.
• Okta: independent IdP with a broad integration ecosystem. Common in SaaS-first organisations.
• JumpCloud: cloud directory for mixed environments, attractive to SMBs that do not want to run Active Directory.
• Twingate and Tailscale: ZTNA and mesh based on WireGuard. Developer-friendly approach, fast deployment, strong in startups and engineering teams.

The practical rule: start with identity (IdP + MFA), add device trust, and only then choose the ZTNA/SSE vendor.

Metrics to measure Zero Trust maturity

The CISA Zero Trust Maturity Model v2 defines five pillars (Identity, Device, Network, Application and Workload, Data) with four maturity levels per pillar: Traditional, Initial, Advanced, Optimal. It is the reference framework for self-assessment and for defending the roadmap before leadership.

Recommended operational KPIs for quarterly reporting to the management committee:

• Percentage of accounts with phishing-resistant MFA enabled.
• Percentage of internal applications published via ZTNA versus VPN.
• Percentage of critical workloads with active L7 microsegmentation.
• Percentage of corporate devices with validated posture and active EDR.
• MTTD (mean time to detect) and MTTR (mean time to respond) for access incidents.
• Percentage of privileged accesses audited with session recording.

Frequently asked questions

Is Zero Trust a product or a strategy?

It is an architectural strategy. Products (ZTNA, IdP, EDR, microsegmentation) are pieces that materialise the strategy, but no product on its own delivers Zero Trust. Buying a box labelled "Zero Trust" without phase 0 and without process alignment is a common anti-pattern.

Do I need to scrap my VPN to get started?

No. A realistic migration takes months, and VPN + ZTNA coexistence for 12 to 18 months is normal. The right question is: which use cases can I move to ZTNA now, and which will still need VPN for a while? A reasonable intermediate goal is to retire VPN for 70 to 80 percent of cases in the first wave.

How much does it cost to implement Zero Trust?

It depends on the starting point. An organisation with a modern IdP, generalised MFA, and EDR already deployed can take on Zero Trust at moderate incremental cost (ZTNA licences, project effort). An organisation without those foundations starts from a higher cost. Rule of thumb: most of the spend goes into people and project work, not licences.

Can an SMB do Zero Trust?

Yes. SMBs even start with an advantage: fewer legacy systems, less organisational complexity. An SMB can reach an Initial-Advanced level on the CISA model in 6 to 9 months by combining a cloud IdP with MFA, EDR on endpoints, and a lightweight ZTNA. See also the guide on cybersecurity for SMEs.

Does Zero Trust eliminate the firewall?

No. The firewall is still needed for traffic that does not fit ZTNA (Internet egress, OT/IoT traffic, base network segmentation). What changes is its role: it stops being the primary control and becomes a defence-in-depth control.

Is ZTNA the same as SASE?

No. ZTNA is a component, SASE (Secure Access Service Edge) is the convergence of several network and security services in the cloud (SD-WAN, ZTNA, SWG, CASB, FWaaS, DLP). SSE is the security-focused subset of SASE. An organisation can start with pure ZTNA without committing to a full SASE.

How long until I see return?

The first visible returns appear in 3 to 6 months with the identity phase: reduction in phishing incidents and credential compromise. The full return in terms of blast radius and attack surface reduction consolidates between months 12 and 18, when ZTNA, microsegmentation, and monitoring are mature.

Related resources

• Cybersecurity audit for businesses: complete guide
• NIS2 audit step by step
• ISO 27001 explained: certification, controls, and process
• What is EDR: endpoint detection and response
• What is PKI: public key infrastructure
• What is social engineering
• What is network and system hardening

Zero Trust implementation with Secra

At Secra we support B2B organisations in designing and deploying Zero Trust architectures with a pragmatic, phased approach. In 4 weeks we deliver a personalised roadmap including:

• Initial assessment against the CISA Zero Trust Maturity Model v2 across the five pillars, identifying current level and a realistic target at 12 and 24 months.
• Reference architecture design adapted to your current stack (Microsoft, Google, AWS, Azure, on-premise, hybrid) and to operational and regulatory constraints.
• Phase-by-phase implementation plan prioritised by return, effort, and dependencies, integrated with your ongoing NIS2, ENS, or ISO 27001 initiatives.
• Optional execution support to accompany the internal team during the most sensitive phases (identity, microsegmentation, VPN retirement).

If your organisation is evaluating a Zero Trust project, a SASE/SSE migration, or needs to structure the roadmap before talking to vendors, contact Secra and we will arrange an initial session at no commitment.