The term “Zero Trust” was popularised by Forrester analyst John Kindervag in 2010. His challenge to the prevailing “castle-and-moat” model was straightforward: location inside a network should not be treated as evidence of trustworthiness. The approach was subsequently formalised in sources such as NIST Special Publication 800-207 and has been translated into practical public-sector roadmaps including the US Cybersecurity and Infrastructure Security Agency (CISA) Zero Trust Maturity Model. Its relevance has grown as cloud services, hybrid work, outsourced delivery and operational technology have made the old distinction between “inside” and “outside” increasingly unreliable.

Explicit verification means authenticating and authorising each access request using the best available evidence: identity, device condition, location, behaviour, the sensitivity of the resource and the risk of the action. The NCSC’s authentication and authorisation principle recommends using multiple signals and applying stronger checks in proportion to risk. In practice, this combines multi-factor authentication (MFA), conditional access and additional checks when circumstances change. The purpose is not to challenge people at every click, but to make stronger verification proportionate to risk.

Leaders should expect explicit verification to draw on more than a password. Relevant evidence may include strong multi-factor authentication, the condition of the device, the sensitivity of the requested action and changes in behaviour or location. The important governance question is whether stronger checks are applied proportionately and whether legitimate users can obtain support when a request is challenged.

Access decisions can be revisited during a session as risk signals change; this is broader than repeatedly authenticating the user. A marked change in location, device condition or behaviour may justify an additional check, a restriction or revocation of access, but the response should reflect the sensitivity of the action and the confidence of the evidence. Leaders should expect policies to balance timely intervention with clear support and recovery routes for legitimate users, and should verify which signals and responses the implementation actually supports.

Device posture checks assess available evidence against security policies, such as patch status, encryption and endpoint protection, before access is granted. Their assurance depends on the quality and freshness of those signals; a passing result does not prove that a device is uncompromised. Microsoft Entra Conditional Access can use device state and other signals when making and enforcing access decisions.

Least privilege limits users, devices and applications to the permissions they need, for only as long as they need them. This is easy to endorse and difficult to sustain: roles change, projects end and emergency permissions become permanent. The Information Commissioner’s Office (ICO) access-control guidance calls for role-appropriate access, prompt removal of privileges that are no longer needed, regular reviews and time limits for temporary permissions. Mature programmes therefore combine accurate joiner-mover-leaver processes with regular access review, just-in-time elevation and close control of privileged accounts.

Just-in-time (JIT) access grants temporary, time-bound permissions for a specific task. For example, a contractor may receive access only for the duration of a project and only to the files needed for that work.

Least privilege is strengthened when access is time-bound and reviewed as work changes. Temporary permissions can support projects, supplier activity and exceptional administration without becoming permanent entitlements, provided that ownership, expiry and review are clear.

Attribute-based access control (ABAC) evaluates attributes associated with the user, device, resource, requested action and surrounding context. It can support more granular and adaptive policies than role-based access control (RBAC), although many organisations use both approaches together rather than treating them as alternatives.

“Assume breach” is a design discipline, not an expression of distrust. It recognises that prevention will sometimes fail and asks whether the organisation can detect compromise quickly, contain it and continue delivering essential services. This aligns with the NCSC’s explanation of Zero Trust, which treats the network as potentially hostile and requires access requests to be evaluated against policy rather than trusted by location. Monitoring, endpoint detection, segmentation and rehearsed response playbooks should work together so that one compromised identity or device does not become an enterprise-wide incident.

Continuous monitoring brings together security information and event management (SIEM), endpoint detection and response (EDR), and extended detection and response (XDR) capabilities so that teams can identify anomalies and investigate them in context. Product capabilities vary, so leaders should assess the quality of the evidence, integration and operational response rather than rely on a general claim of artificial intelligence (AI)-driven detection.

Automated response can isolate a compromised device or revoke access when predefined conditions are met. For example, endpoint controls may quarantine a device that exhibits behaviour consistent with ransomware, while preserving an escalation and recovery route for legitimate activity.

Zero Trust Network Access (ZTNA) can reduce lateral movement by limiting users and devices to approved applications rather than granting broad network access. It supports containment, but it does not remove the need for segmentation, endpoint security, monitoring and incident response.

Micro-segmentation limits how far an attacker or an error can travel. Rather than relying on a flat internal network, organisations separate critical applications, administration paths and workloads according to risk. The practical challenge is to understand real dependencies before enforcing boundaries; poorly designed segmentation can interrupt legitimate services as readily as malicious movement.

• Network Isolation: Critical systems (e.g., databases, admin consoles) are separated from the rest of the network.
• Application segmentation: applications have policy-controlled boundaries that permit required connections while reducing opportunities for attackers to move between them.
• Workload Segmentation: Cloud workloads (e.g., containers and virtual machines (VMs)) are protected individually.

Continuous monitoring provides the evidence needed to revisit trust decisions. Identity, endpoint, application, cloud and network signals are brought together to identify unusual behaviour and support proportionate response. Automation can accelerate containment, but experienced oversight remains essential: rules and models can be incomplete, and a technically unusual action may still be legitimate in its operational context.

User and entity behaviour analytics (UEBA) uses statistical and machine-learning techniques to identify activity that differs from established patterns, such as unusual access times, locations or resource use. These signals can help teams prioritise investigation, but they require context and human judgement because unusual behaviour is not necessarily malicious.

Leaders do not need to manage the distinctions among EDR, SIEM and XDR in operational detail, but they should expect identity, endpoint, network, application and cloud evidence to be brought together coherently. The important questions are whether material signals can be correlated, whether teams can investigate them in context and whether response responsibilities are clear.

Leadership should begin by agreeing why Zero Trust matters to the organisation and which outcomes it is expected to support. That may include protecting a critical public service, reducing privileged-access risk, improving supplier assurance or making hybrid work more resilient. Accountability should be shared: business and service owners remain responsible for operational outcomes, technology leaders for architecture and delivery, and security and risk leaders for challenge, assurance and evidence. Frameworks such as CISA’s Zero Trust Maturity Model and the NCSC architecture design principles can inform the discussion, but they should be adapted to the organisation rather than treated as pass-or-fail assessments.

An enterprise-wide rollout is rarely the best starting point. Leaders should identify the services and data whose disruption or compromise would cause the greatest operational, financial, regulatory or public harm, then focus on the access paths that create the most material exposure. Privileged accounts, remote administration, third-party access and poorly governed service identities often warrant early attention. The aim is to select a manageable area where improved identity, access, segmentation and monitoring can reduce risk without placing essential delivery under unnecessary strain.

Change should be introduced in phases, with clear criteria for moving from a limited deployment to wider adoption. Each phase should test security effectiveness, service continuity, user experience, support requirements and the organisation’s ability to respond when controls behave unexpectedly. Leaders have an important role in making trade-offs visible: stronger assurance may add friction; tighter segmentation may expose hidden dependencies; and automation may accelerate response while creating new oversight needs. Decisions should be recorded, reviewed and supported by credible fallback arrangements rather than left to individual project teams.

Progress should be measured through organisational outcomes rather than product deployment. Useful indicators include fewer standing privileges, reduced exposure of critical services, stronger control of supplier access, faster detection and containment, and a user experience that remains workable. Quantitative measures should be accompanied by feedback from service teams and users, because friction and workarounds often reveal where policy or implementation needs attention. Leaders should communicate the purpose of changes, give teams time to build capability and treat early difficulties as opportunities to learn rather than evidence that the programme has failed.

Older systems, including mainframes and unsupported software, may not support modern Zero Trust controls such as multi-factor authentication or micro-segmentation.

Legacy systems may not support modern authentication, segmentation or monitoring controls, and immediate replacement may be impractical. Leaders should therefore agree how exposure will be reduced in the interim through controlled access, isolation, enhanced monitoring and documented exceptions, while maintaining a realistic plan for upgrade, replacement or retirement. Any overlay should be treated as a compensating control rather than evidence that the underlying constraint has disappeared.

New authentication and access controls can create understandable concerns if they add friction, interrupt established workflows or are introduced without enough explanation. These concerns are useful evidence: they can reveal where policy, technology or support arrangements need to be adjusted.

Improve the user experience without treating all MFA methods as equally protective. Prioritise phishing-resistant FIDO2 authenticators, including suitable hardware security keys, where supported, and select accessible options with reliable recovery routes. Biometrics can provide a convenient way to unlock a suitable authenticator, but they are not automatically a complete MFA method on their own. Where push notifications remain necessary, use safeguards such as number matching rather than simple approve-or-deny prompts, and treat them as an interim option rather than equivalent to phishing-resistant authentication.

Communicate the benefits in terms that matter to users while keeping claims appropriately qualified.Microsoft’s documentation for its managed Conditional Access policies reports that MFA reduces the risk of compromise by more than 99%. Treat this as a vendor-reported claim about MFA in that context, not as a measured result for the organisation, a guarantee for every authentication method or an estimate of the reduction in overall cyber risk.

User experience should be treated as part of control effectiveness. Accessible authentication options, well-designed recovery routes and early feedback from teams with different working patterns can reveal where a policy creates avoidable friction or encourages workarounds. Pilot groups should therefore be chosen for the range of services and user needs they represent, not simply because they are already comfortable with technology.

Some proprietary Zero Trust services can create dependencies that make future migration or integration more difficult. These risks are easier to manage when organisations understand data portability, contractual exit arrangements, standards support and integration requirements before making long-term commitments.

Use interoperable architectures and well-documented interfaces where they meet the organisation’s requirements. NIST SP 800-207 provides a vendor-neutral Zero Trust architecture, while OpenZiti is an open-source implementation of zero-trust networking rather than a standard.

A multi-vendor approach can reduce dependence on a single provider, but it can also increase integration, support and accountability challenges. Leaders should ask whether responsibilities remain clear across identity, endpoint and access services, whether evidence can be brought together during an incident, and whether the additional complexity is justified by resilience and portability benefits.

Cloud-agnostic designs can improve portability in some multi-cloud environments, but avoiding every provider-specific service may sacrifice useful integration or operational capability. Leaders should assess concentration risk, exit arrangements, interoperability and total cost before deciding where portability is essential.

Zero Trust implementations can be complex and costly, especially for large organisations with legacy systems.

Early investment should focus on the areas where material risk can be reduced without creating disproportionate operational strain. Stronger authentication, improved privileged-access control and carefully selected ZTNA use cases may offer useful starting points, but their value and sequence will depend on the organisation’s services, dependencies and existing controls.

Managed services may be helpful where internal capacity is limited or where specialist coverage is difficult to sustain. Before relying on a provider, organisations should remain clear about accountability, access to evidence, incident responsibilities, service resilience and how capability will be retained or developed internally.

Cloud-based capabilities may reduce some infrastructure and maintenance demands, but they also introduce subscription costs, integration work, data considerations and supplier dependencies. Leaders should compare total cost, operational resilience, portability and internal capability requirements rather than assume that a cloud delivery model will necessarily be cheaper.

Zero Trust does not create automatic compliance, but carefully mapped controls can support risk-based obligations concerning access control, authentication, logging, monitoring, incident handling, resilience and recovery. The United Kingdom General Data Protection Regulation (UK GDPR), the European Union (EU) Directive on measures for a high common level of cybersecurity (NIS2) and the Payment Card Industry Data Security Standard (PCI DSS) differ in scope and legal effect, and none should be treated as prescribing Zero Trust as a named architecture. Organisations should trace each control to the specific requirement, accountable owner and evidence that apply in their context rather than rely on a general claim of compliance.

Tools can help collect access, authentication, logging and monitoring evidence, but reporting features do not make a service or architecture compliant on their own. Leaders should confirm that evidence is complete, retained appropriately and mapped to the specific obligation, control owner and assurance process that apply.

AI-assisted capabilities are beginning to move some Zero Trust decisions beyond fixed rules towards more adaptive analysis. They may help teams identify patterns and respond more quickly, but their value will depend on data quality, transparency, proportionate human oversight and careful testing in the organisation’s own environment.

Quantum computing creates a long-term risk for widely used public-key cryptography. NIST finalised its first three post-quantum cryptography standards in 2024 and advises organisations to identify where vulnerable algorithms are used and begin planning migration. For Zero Trust programmes, the practical implication is to include cryptographic inventory, agility and supplier roadmaps in architectural decisions rather than treat quantum resistance as a separate future project.

The growth of connected devices and operational technology expands the range of identities, protocols and safety considerations that a Zero Trust programme must address. CISA’s publication Adapting Zero Trust Principles to Operational Technology explains that the approach requires tailored adaptation and collaboration across IT, OT and cybersecurity teams. Controls that work well in office IT may need careful adjustment where availability, safety and long equipment lifecycles are central concerns.

Managed Zero Trust services may help organisations that cannot sustain every specialist capability internally, but the sourcing decision requires careful governance. Leaders should remain clear about accountability, access to operational evidence, incident responsibilities, resilience, exit arrangements and the capabilities that must remain within the organisation.