Zero trust security: a practical strategy

Zero trust is an architectural approach to verifying access requests. Buying a product labelled Zero Trust Network Access, or ZTNA, does not implement the whole approach.

This article covers identity verification, device health and least-privilege access. It includes a readiness assessment and phased implementation plan.

---

The zero trust myth vs reality

Separate architectural decisions from product purchasing before you plan a rollout.

What zero trust is not

Myth 1: zero trust is a product you can buy. A firewall, VPN, identity provider or endpoint agent can support the architecture. Buying one does not establish the policies, asset inventory and operational processes for every resource.

Myth 2: zero trust means trusting nothing. The name is unfortunately misleading. Zero Trust does not mean paranoid distrust of everything. It means verifying everything explicitly rather than relying on implicit trust from network location.

Myth 3: zero trust replaces your existing security. Zero Trust augments and reorganises your security controls. It does not eliminate the need for firewalls, encryption, or endpoint protection. It changes how these controls coordinate and make decisions.

Myth 4: zero trust is only for large enterprises. While implementation complexity scales with organisation size, the principles apply to organisations of any size. A 50-person company can implement Zero Trust principles with standard tooling.

What zero trust actually is

Zero Trust is a security model based on a simple principle: "Never trust, always verify."

The traditional perimeter model assumed that connections from inside the corporate network could be trusted. This model made sense when:

• Employees worked in offices
• Servers lived in data centres
• Applications were on-premises
• The network perimeter was well-defined

Many organisations now combine office networks, remote work, hosted services and SaaS. Access controls need to account for each environment without assuming that a connection from the office is safe.

Zero Trust assumes the network is already compromised. Every access request must be explicitly verified against:

• Identity: Who is making the request?
• Device: What device are they using, and is it healthy?
• Context: When, where, and why are they requesting access?
• Resource: What specifically are they trying to access?
• Privilege: Should they have access to this resource at this time?

Only after all these factors are verified does the system grant the minimum access required.

The shift in thinking

NIST SP 800-207 says network location or asset ownership alone must not grant implicit trust. Segmentation and perimeter controls still help restrict access and contain an incident. The related identity security guide considers the identity part of that design.

---

The three pillars of zero trust

This guide groups the work into identity, device health and least privilege. These are planning categories, not a complete official maturity framework.

Pillar 1: identity verification (the foundation)

Verify the identity making the request before deciding which resources it can access.

A stolen credential can let an attacker impersonate its owner. It does not make network controls useless: segmentation, application policy and device checks can still deny access or limit movement. Combine these controls so a successful login does not grant unrestricted access.

Essential identity controls:

Multi-factor authentication (MFA): Prioritise MFA for privileged and externally accessible accounts. Where a legacy system cannot support it, document compensating controls and an upgrade plan. Authentication methods have different limitations:

• SMS/Voice codes: Vulnerable to SIM swapping and interception. Assess their limits before relying on them for sensitive access.
• Time-based codes (TOTP): Better, but still phishable.
• Push notifications: Convenient but susceptible to push fatigue attacks.
• Hardware keys (FIDO2/WebAuthn): Phishing-resistant authentication.
• Passkeys: Phishing-resistant authentication, with local activation such as a device PIN or biometric check. Biometrics are not required for every passkey.

Move toward phishing-resistant MFA for all privileged access and sensitive systems.

Single sign-on (SSO): SSO provides centralised authentication controls:

• A single authentication point for all applications
• Centralised logging and auditing
• One place to revoke access when employees leave
• Consistent policy enforcement across applications

Evaluate SSO for supported applications and test account revocation end to end, including existing sessions and API tokens. Keep a documented recovery route if the identity provider is unavailable. For unsupported applications, compare replacement with restricted access and other compensating controls.

Identity governance and administration (IGA): Knowing who someone is means nothing if you do not manage what they are allowed to do:

• Automated provisioning and deprovisioning
• Access certification and reviews
• Segregation of duties enforcement
• Access request workflows

Conditional access policies: Identity verification should not be binary. Conditional access evaluates context:

• Is this a known device?
• Is the location unusual?
• What is the user trying to access?
• What is the risk level of this request?

Based on these factors, you might allow access, require additional verification, or deny access entirely.

Pillar 2: device health

Verifying identity is necessary but insufficient. You must also verify the device making the request.

Consider a CEO who authenticates with a username, password and hardware key from an infected, unmanaged personal iPad. The device check can still lead to a denied request despite successful identity verification.

The device is part of the trust calculation because a compromised device can compromise everything the user accesses from it.

Device health signals:

• Management status: Is this a managed corporate device or a personal device?
• OS patch level: Is the operating system current on security updates?
• Disk encryption: Is the device encrypted at rest?
• Endpoint protection: Is EDR/antivirus running and healthy?
• Firewall status: Is the local firewall enabled?
• Jailbreak/root detection: Has the device been tampered with?
• Compliance status: Does the device meet your baseline requirements?

Device trust tiers:

Not all devices need the same trust level. Consider a tiered approach:

Technical implementation:

Device health verification typically requires:

• Mobile Device Management (MDM) for mobile devices
• Endpoint Detection and Response (EDR) for computers
• Device compliance policies defining minimum requirements
• Conditional access integration to enforce device requirements at authentication

Your architecture needs a reliable way to obtain and enforce the relevant device health signals. An integration between identity and device management is one way to provide them.

Pillar 3: least privilege access

The third pillar addresses what happens after identity and device are verified: granting the minimum access required, for the minimum time required.

The traditional model granted broad access. Once authenticated, users could often reach many resources they did not need. Zero Trust inverts this: access is denied by default, and explicitly granted only to specific resources.

Least privilege principles:

Default deny: If access is not explicitly granted, it is denied. This is the opposite of traditional "allow by default" networks.

Just enough access (JEA): Grant access only to the specific resources needed for the specific task. A developer does not need access to the HR database. A marketing analyst does not need access to production servers.

Just-in-time access (JIT): Just-in-time access grants elevated privileges for a defined task and duration. Configure expiry, approval and monitoring, then test that permissions and sessions stop as intended. Time limits reduce standing access; they do not prevent misuse during an authorised session.

Micro-segmentation: In a flat network, devices can communicate across the network without segmentation. Micro-segmentation creates secure zones, limiting lateral movement. The printer cannot talk to the database server. The development environment cannot reach production.

Application-level access: Instead of network access, grant application-level access. Users connect to the specific application they need, not to the network where the application lives. This eliminates the concept of "being on the corporate network."

Implementation considerations: Test each control on a representative application. Confirm that an unauthorised identity or device is refused, approved work still completes, privileged access expires and emergency recovery remains available. Record the evidence and rollback owner.

---

Zero trust maturity model

The following six-stage scale is an illustrative planning aid developed for this guide. It is not a NIST or CISA assessment and cannot certify security maturity.

An illustrative six-stage planning scale

Use the descriptions to identify missing controls for a particular application. Do not infer a security outcome from a high score or assume that more automation is always appropriate.

Self-assessment checklist

For each item, record an owner, evidence, the current gap and the next action. If you use the optional 0-5 score, define 0 as absent, 1 as planned, 2 as piloted, 3 as deployed within the agreed scope, 4 as tested, and 5 as monitored and regularly reviewed. An average can hide a critical gap, so review every missing control separately.

Identity (score 0-5 for each):

• All users have MFA enabled for all external access
• Phishing-resistant MFA deployed for privileged accounts
• SSO implemented for all supported applications
• Automated provisioning/deprovisioning in place
• Regular access reviews conducted and actioned
• Conditional access policies evaluate context
• Identity threat detection monitors for anomalies

Device (score 0-5 for each):

• Device inventory is complete and accurate
• MDM deployed on all mobile devices accessing corporate data
• EDR deployed on all endpoints
• Device compliance policies defined and enforced
• Conditional access integrates device health signals
• BYOD policy clearly defined with technical controls
• Unmanaged device access restricted appropriately

Network/access (score 0-5 for each):

• Network segmentation separates critical assets
• ZTNA deployed for remote application access
• VPN dependency reduced or eliminated
• Micro-segmentation limits lateral movement
• Application-level access replaces network-level access
• Default deny posture for new connections
• Visibility into all network traffic

Privileged access (score 0-5 for each):

• Privileged accounts inventoried and monitored
• PAM solution manages privileged credentials
• JIT access implemented for administrative tasks
• Session recording for sensitive access
• Separation of duties enforced
• Break-glass procedures documented and tested
• Regular privileged access reviews conducted

Worked example: A payroll application has MFA, but an unmanaged device can still download every employee record. Record the identity control as deployed and the device/data-access gap as unresolved. Pilot managed-device restrictions with payroll staff, test the emergency access route and confirm that legitimate payroll work still completes before wider enforcement. A combined score must not conceal that unresolved data exposure.

---

The zero trust adoption roadmap

The schedule below is an illustrative sequencing plan, not a promised implementation time or mandatory waiting period. Apply urgent fixes as soon as safely possible. Larger migrations need application testing, rollback and staff support.

Instead, approach Zero Trust in phases, starting with your highest-value targets and expanding methodically.

Phase 1: foundation (months 1-6)

Objectives:

• Establish identity as the primary control plane
• Achieve comprehensive MFA coverage
• Gain visibility into current access patterns

Week 1-4: assessment and planning

• Conduct current state security assessment
• Inventory all applications and their authentication methods
• Map data flows and identify critical assets ("Crown Jewels")
• Assess existing identity infrastructure
• Document current network architecture
• Identify stakeholders and form Zero Trust working group
• Develop phased implementation plan

Week 5-12: identity foundation

• Deploy or upgrade identity provider (Entra ID, Okta, etc.)
• Enable MFA for all external access
• Implement SSO for high-priority applications
• Configure basic conditional access policies
• Begin automated provisioning/deprovisioning
• Deploy phishing-resistant MFA for IT administrators

Week 13-24: device visibility

• Complete device inventory across all platforms
• Deploy MDM for mobile devices
• Ensure EDR coverage on all endpoints
• Define initial device compliance baselines
• Integrate device signals with identity provider
• Establish BYOD policy and technical controls

Phase 1 checkpoint:

Before proceeding to Phase 2, validate:

• MFA enabled for 100% of external access
• SSO implemented for top 10 applications
• Conditional access policies active
• Device inventory 95%+ complete
• MDM/EDR coverage on all managed devices
• Stakeholder support confirmed

Phase 2: crown jewels protection (months 7-12)

Objectives:

• Protect most critical applications with full Zero Trust controls
• Implement ZTNA for sensitive application access
• Deploy PAM for privileged accounts

Crown jewels identification:

Your "Crown Jewels" are the systems and data that would cause the most damage if compromised. Typically:

• Financial systems (ERP, banking, payment processing)
• Customer data repositories (CRM, databases)
• Intellectual property (source code, designs, research)
• HR systems (employee data, payroll)
• Executive communications

Week 25-36: ZTNA deployment

• Select ZTNA solution aligned with architecture
• Deploy ZTNA for Crown Jewels applications
• Configure application-level access policies
• Integrate with identity and device health signals
• Train IT staff on ZTNA administration
• Begin phased user migration from VPN

Week 37-48: privileged access management

• Inventory all privileged accounts
• Deploy PAM solution (CyberArk, BeyondTrust, etc.)
• Implement password vaulting for admin accounts
• Configure JIT access for administrative tasks
• Enable session recording for sensitive access
• Conduct privileged access review

Phase 2 checkpoint:

• Crown Jewels applications protected with ZTNA
• PAM deployed for IT administrative access
• JIT access operational for routine admin tasks
• VPN dependency reduced for pilot groups
• Metrics showing reduced attack surface

Phase 3: broad deployment (months 13-24)

Objectives:

• Extend Zero Trust controls to all applications
• Implement micro-segmentation
• Achieve continuous verification

Week 49-72: application expansion

• Deploy ZTNA for Tier 2 applications
• Migrate remaining users from VPN
• Extend SSO to all supported applications
• Implement risk-based authentication
• Configure automated response to anomalies

Week 73-96: network transformation

• Design micro-segmentation architecture
• Deploy initial micro-segmentation for critical segments
• Implement network traffic analysis
• Reduce lateral movement paths
• Validate segmentation effectiveness through testing

Phase 3 checkpoint:

• ZTNA deployed for all appropriate applications
• VPN eliminated or limited to exceptions
• Micro-segmentation protecting critical assets
• Continuous monitoring operational
• Incident response processes updated for Zero Trust

Phase 4: optimisation (ongoing)

Objectives:

• Continuous improvement based on metrics
• Advanced automation and AI-driven decisions
• Regular maturity reassessment

Ongoing activities:

• Regular access reviews and certification
• Policy refinement based on operational data
• Technology refresh as capabilities evolve
• Red team exercises to validate controls
• Maturity assessment against framework
• Stakeholder reporting and ROI demonstration

---

Vendor landscape overview

Compare vendors by the access-control functions they provide and the systems they need to integrate with.

Define the required capability

Ask bidders to demonstrate the control on an application you operate. An identity provider should show authentication and account recovery; a privileged-access system should show approval, expiry and revocation; network controls should show allowed and denied paths. Check licensing, supported protocols and integration prerequisites in the vendor's current documentation.

Vendor selection considerations

When evaluating vendors, consider:

Integration capability: Zero Trust requires components to share signals. Vendors must integrate with your existing identity, endpoint, and network infrastructure.

Deployment model: Cloud-native vs on-premises vs hybrid. Your infrastructure strategy should guide this choice.

User experience: Security that frustrates users gets bypassed. Evaluate the user experience for each solution.

Operational complexity: More tools means more operational overhead. Consider managed services or converged platforms.

Total cost of ownership: Beyond licensing, consider implementation, training, integration, and ongoing operations.

Vendor viability: Zero Trust is a long-term architecture. Ensure vendors will be around for the journey.

Avoid vendor traps

The "complete solution" myth: No single vendor delivers complete Zero Trust. You will need multiple integrated components.

The checkbox approach: Do not buy tools to check compliance boxes. Buy tools that genuinely improve your security posture.

The best-of-breed vs platform debate: There is no universal right answer. Best-of-breed offers capability but complexity. Platforms offer integration but potential gaps. Choose based on your operational maturity and resources.

---

Migration priority matrix

Not all applications and users should migrate at the same time. Prioritise based on risk and impact.

Prioritisation factors

Data sensitivity: What is the classification of data accessible through this system?

User privilege level: Are users accessing administrative functions or routine tasks?

Attack surface: Is the application internet-facing? Does it process untrusted input?

Business criticality: What is the impact of downtime or compromise?

Technical feasibility: Does the application support modern authentication?

User impact: How disruptive will the migration be for users?

---

Common implementation challenges

Zero Trust implementations frequently encounter these challenges. Anticipate them.

Technical challenges

Legacy application compatibility: Some applications do not support federated authentication through SAML or OIDC. SCIM is a provisioning protocol, not an authentication method. Options include:

• Application proxy solutions that front legacy apps
• Vendor upgrades or replacements
• Isolated access with additional compensating controls

Network visibility gaps: You cannot protect what you cannot see. Ensure comprehensive visibility into network traffic before implementing micro-segmentation.

Integration complexity: Zero Trust requires components to share information. Budget significant effort for integration work.

Organisational challenges

User resistance: Zero Trust may introduce additional verification steps. Communicate the "why" before the "what." Emphasise that security protects users, not just the company.

Stakeholder fatigue: Multi-year transformations risk losing executive attention. Deliver visible wins early and maintain regular progress reporting.

Skills gaps: Zero Trust requires new skills in identity, cloud security, and modern architecture. Plan for training and potentially external support.

Operational challenges

Alert fatigue: More visibility means more alerts. Invest in tuning and automation to prevent analyst burnout.

Policy complexity: Conditional access policies can become complex quickly. Document policies clearly and review regularly.

Incident response updates: Zero Trust changes how incidents unfold. Update playbooks and train responders on the new architecture.

---

Measuring zero trust success

Use measures tied to your own scope and baseline. The targets below are examples to agree with service owners, not universal security thresholds.

Key performance indicators

Demonstrating ROI

Zero Trust investments compete for budget. Demonstrate value through:

• Reduced breach risk: Quantify risk reduction using frameworks like FAIR
• Compliance efficiency: Reduced audit findings, faster evidence collection
• Operational savings: VPN infrastructure retirement, reduced help desk burden
• Business enablement: Secure remote work, faster onboarding, M&A integration

---

Zero trust and the modern workplace

Access decisions should reflect how people and systems use resources.

Remote and hybrid work

As I explored in Asynchronous IT Leadership, the remote-first world is here to stay. Zero trust does not assume a network is trusted merely because a user is connected to it.

A VPN can restrict routes and access with firewall rules; it does not necessarily grant access to the whole network. Application-specific access can reduce unnecessary connectivity. Compare the controls, protocols, availability and user experience of each option rather than treating VPN replacement as a security outcome by itself.

Cloud and SaaS

Cloud applications still need network controls where applicable, alongside identity policy, application security and data protection. Apply the same access principles across environments, while testing each platform's implementation and limits.

As discussed in SaaS Governance Strategies, managing access to SaaS applications requires robust identity controls. Zero Trust provides the architectural foundation for SaaS security.

API-first architecture

Modern applications are collections of APIs. As I covered in API-First Enterprise Strategy, APIs need security too. Verify identity, check context and grant minimum access for both human users and service accounts accessing APIs.

---

Quick reference: implementation checklist

Use this checklist to track your Zero Trust implementation:

Foundation:

• Executive sponsor identified and engaged
• Zero Trust working group formed
• Current state assessment completed
• Crown Jewels identified and documented
• Phased implementation plan approved
• Success metrics defined

Identity:

• Identity provider deployed or upgraded
• MFA enabled for all external access
• Phishing-resistant MFA for privileged users
• SSO implemented for priority applications
• Conditional access policies configured
• Automated provisioning/deprovisioning operational
• Access review process established

Device:

• Device inventory complete
• MDM deployed for mobile devices
• EDR deployed on all endpoints
• Compliance baselines defined
• Device health integrated with access decisions
• BYOD policy and controls implemented

Access:

• ZTNA selected and deployed
• Crown Jewels applications migrated to ZTNA
• VPN dependency reduced
• PAM deployed for privileged accounts
• JIT access configured for admin tasks
• Network segmentation improved

Operations:

• Monitoring and alerting operational
• Incident response playbooks updated
• User training completed
• Operational documentation complete
• Regular maturity assessments scheduled

---

The reality check

A broad zero trust implementation can require several years of funding, integration work and changes to how teams manage access.

Assess the access risks in your own systems before choosing the next implementation phase.

Start small: Protect your Crown Jewels first. Pilot access controls for a critical application and verify that they block the unwanted access paths without disrupting its service.

Build incrementally: Each phase delivers value while building toward the complete architecture.

Accept imperfection: You will never achieve Zero Trust "perfection." The goal is continuous improvement in security posture.

Focus on architecture, not products: The vendors will come and go. The principles endure.

---

Conclusion

A zero trust programme should produce enforceable access decisions and evidence that those decisions work.

Evaluate identity verification, device health and least-privilege controls together. Check how each proposed product contributes to those controls.

As I discussed in Identity is the New Firewall, identity is one input to an access decision. Test it alongside device, application and network controls.

Start with an access review for a critical application and record the changes needed.

---

Building your zero trust architecture

My IT management services and IT compliance services help organisations assess access controls and plan a phased implementation. Agree which risks to reduce and how to test the changes before purchasing additional tools.

Book a consultation with a list of your critical applications, current identity provider and the access problem you need to solve. We can identify the first pilot, its acceptance tests and the dependencies that need attention.

---

Related reading: Identity is the New Firewall explores the identity foundation that Zero Trust requires. SaaS Governance Strategies addresses access control for cloud applications. API-First Enterprise Strategy covers API security in modern architectures.