- Zero Trust is a security architecture, not a product. Its core principle is: never trust implicitly, always verify explicitly, enforce least privilege, and assume breach has already occurred.
- The model was introduced by John Kindervag at Forrester Research in 2010 and formalised by NIST in Special Publication 800-207 in 2020, which remains the authoritative implementation reference.
- Zero Trust has five pillars: Identity, Devices, Network, Applications, and Data. Most organisations start with Identity, which delivers the largest risk reduction per unit of effort.
- Conditional Access policies in Microsoft Entra ID or equivalent identity providers are the primary enforcement mechanism for the identity and device pillars and are accessible to organisations of any size.
- Zero Trust does not require replacing your entire infrastructure. Existing investments in MFA, device management, and network segmentation all map to the framework and can be extended incrementally.
- A well-implemented Zero Trust programme satisfies the majority of NIS2 Article 21 access control requirements and ISO 27001 Annex A identity and network controls.
Why the perimeter is gone
Traditional network security was built on a boundary assumption: everything inside the corporate network is trusted, everything outside is not. A firewall at the perimeter separated the two zones. Remote workers connected through VPN to bring themselves inside the boundary. The model worked reasonably well when most users sat in the office, most applications ran on-premises, and most data lived on servers you could physically touch.
That world no longer exists for most organisations. Users work from home, cafes, and client sites. Applications have migrated to Microsoft 365, Salesforce, AWS, and dozens of other cloud platforms. Partners and contractors connect from their own networks. Supply chain integrations create automated trust relationships between organisations. Each of these shifts pushes critical data and access beyond the perimeter, yet perimeter-based security still treats the corporate network as the trust boundary.
The result is predictable. An attacker who compromises a single laptop, a phished user account, or a poorly secured VPN credential is immediately inside the trusted zone. From there they can move laterally across the network with relatively little friction, because internal traffic is largely uninspected and internal systems assume trust from anything that arrived through the right network entry point.
Zero Trust removes the implicit trust associated with network location. Your identity, your device health, and the specific resource you are trying to reach determine what you can access. The network you are connecting from is irrelevant.
The five pillars
NIST SP 800-207 organises Zero Trust around five control planes. Organisations do not need to implement all five simultaneously. Most start with Identity, which addresses the most common initial access vector (compromised credentials), and expand from there.
Starting with identity
Most organisations implementing Zero Trust for the first time focus on identity because it addresses the most common attack path, is achievable with existing tools, and does not require network infrastructure changes.
Conditional Access policies
Conditional Access is the enforcement engine of identity-first Zero Trust. Each sign-in generates a set of signals: the user's identity, the device they are using, the location they are connecting from, the application they are trying to reach, and any risk signals from identity protection engines. A policy evaluates these signals and decides: allow, block, or require additional verification.
A baseline set of Conditional Access policies for most organisations should include: requiring MFA for all users on all cloud applications; blocking sign-ins from countries where you have no business presence; blocking legacy authentication protocols that cannot support MFA; requiring device compliance for access to sensitive applications; and applying risk-based sign-in policies that require step-up authentication when the identity protection engine detects anomalous behaviour.
Privileged Identity Management
Administrative accounts represent the highest-value target in any environment. Zero Trust requires that administrative access is never persistent. PIM tools such as Entra ID Privileged Identity Management require an administrator to explicitly request, justify, and activate a privileged role for a time-limited session. Outside of active sessions, the account holds no administrative permissions. This means a compromised administrative account credential provides no persistent access without the activation workflow.
Microsoft 365 Business Premium includes Entra ID Conditional Access, Microsoft Intune for device management, Microsoft Defender for Business as an endpoint detection platform, and Defender for Cloud Apps as a CASB. This single licence covers the identity, device, and application pillars for most SMEs without requiring additional products. The configuration is the difficult part, not the licensing.
Device trust and compliance
Knowing that a legitimate user is signing in is not enough if the device they are using is compromised. A user account with valid MFA credentials, signing in from a device that is running unpatched software or has an active malware infection, represents a genuine access risk even after successful authentication.
Device compliance policies in Intune or Jamf define the minimum security posture required for a device to be considered trusted: operating system version minimums, encryption requirements, EDR agent presence, screen lock configuration, and jailbreak or root detection for mobile devices. Conditional Access checks device compliance at sign-in and blocks access for non-compliant devices.
Organisations that allow personal device access can implement a split model: managed devices receive full access to corporate resources; unmanaged personal devices receive browser-only access to specific applications through a reverse proxy, with DLP policies enforced at the session layer to prevent data downloads.
Network segmentation in practice
Full microsegmentation is a complex undertaking, but the principle can be applied incrementally. Start by segmenting your most sensitive assets from the rest of the network: finance systems, identity infrastructure (Active Directory domain controllers), backup systems, and operational technology if present. These segments should have explicit deny-by-default rules governing inbound connections, with only the specific traffic flows required for legitimate use permitted.
ZTNA products from vendors including Cloudflare Access, Zscaler Private Access, and similar platforms sit in front of internal applications and enforce identity and device checks before establishing a connection. The user's device never joins the corporate network; instead it establishes an application-level tunnel to the specific service. This eliminates lateral movement from VPN session compromise entirely.
Zero Trust and regulatory compliance
Zero Trust controls map directly to requirements across the major frameworks applicable to European organisations.
NIS2 (Article 21) requires access control policies, multi-factor authentication, and network security measures for entities in scope. The identity and network pillars of Zero Trust directly address each of these. Device compliance policies address the endpoint security requirement. Logging and monitoring of all access attempts satisfies the audit requirements.
ISO 27001 Annex A controls A.5.15 (access control), A.5.16 (identity management), A.5.17 (authentication information), A.8.20 (network security), and A.8.22 (network segregation) are all addressed by a Zero Trust implementation. Organisations implementing Zero Trust as part of an ISO 27001 programme will find that the security controls required overlap substantially.
DORA requires ICT security measures including logical network segmentation and multi-factor authentication for financial entities. Zero Trust architecture provides a coherent framework for meeting these requirements rather than addressing each obligation independently.
Zero Trust does not assume you can prevent every breach. It assumes breach has already occurred, and asks: how much can an attacker actually reach from their initial foothold?