8-Step Cisco Zero Trust Rollout: Avoid May 2026 EKU Outages

Zero Trust for Cisco is an identity-first architecture built from integrated components, universal ZTNA, Secure Access, Secure Client, Secure Firewall Threat Defense with Firewall Management Center, Identity Services Engine and Duo, that enforces least-privilege access instead of broad network trust. The result is reduced lateral movement, tighter control over hybrid work access and a measurable drop in exposed attack surface. The sections below walk through the mapping to NIST principles, the core components, and a practical implementation checklist.

TL;DR:

Certificate management must be completed before deployment, especially due to upcoming restrictions on Client Authentication EKU certificates by May 2026.

Infrastructure should be prepared through inventory, system upgrades, and policy definition prior to pilot, with a focus on trusted network detection and latency testing.

Identity integration involving ISE, Duo, and certificate validation is complex; explicit policy sets and network entries are essential to prevent authentication failures.

Zero Trust implementation benefits include reduced lateral movement, improved visibility, and application-specific access, with Cisco’s architecture extending existing firewall investments.

Re-solution

Strengthen Your Cisco Security Posture

Re-Solution helps organisations assess infrastructure, connectivity and security requirements across Cisco environments.

✓Infrastructure Audits
✓Network Surveys
✓Security and Compliance Solutions

Explore Cisco solutions

What zero trust means and how Cisco maps NIST principles to products
Core Cisco components you must know
How universal ZTNA works: architecture and traffic flow
Prerequisites, limits and urgent notices to avoid deployment traps
Implementation checklist: pilot to production tasks
Identity and posture integrations: ISE, Duo and common pitfalls
Use cases and business benefits
Re-Solution perspective and proof points
How Re-Solution can help: services and next steps
FAQ
Sources

What zero trust means and how Cisco maps NIST principles to products

Zero Trust is not a product category. It is a security model defined by NIST SP 800-207, which describes an identity-centric approach requiring continuous verification of users, devices and requests regardless of where they originate. The standard rejects the old idea of a trusted internal network and an untrusted external one, replacing it with per-session, least-privilege access decisions backed by continuous diagnostics.

Cisco translates that standard into three practical pillars that shape how its products are grouped and sold:

User and device: identity verification, posture checks and endpoint trust before any access is granted.
Network and cloud: segmentation, encrypted transport and policy enforcement points that sit between users and resources.
Application and data: per-application access controls that hide resources from discovery and limit what an authenticated session can reach.

This framing matters because it explains why Zero Trust Network Access replaces the VPN model rather than simply hardening it. A traditional VPN grants broad network-level access once a user authenticates, which means a compromised laptop or stolen credential can reach far more than it should. ZTNA, by contrast, grants access to a single application or service at a time, continuously re-evaluates trust, and hides everything else from view. For organisations weighing Cisco Zero Trust solutions against a VPN refresh, this distinction is usually the deciding factor.

Core Cisco components you must know

A Cisco Zero Trust deployment is a set of integrated products, each responsible for a distinct layer of the control and data plane. Understanding the division of labour avoids a lot of confusion during design.

Secure Access: the cloud-hosted control plane and policy engine. It issues access tokens, holds the private resource catalogue and brokers trust decisions centrally.
Secure Client: the endpoint agent that enrols devices into Zero Trust, establishes mutual TLS to Secure Access and enforces local policy decisions on the device itself.
Secure Firewall Threat Defense (FTD) and Firewall Management Center (FMC): the on-premises enforcement and management layer. FTD inspects traffic and applies policy; FMC configures and pushes that policy out to FTD devices.
Cisco Identity Services Engine (ISE): the identity, posture and policy orchestration hub, deciding who a user is, what state their device is in, and what that combination is allowed to do.
Duo (Cisco Secure Access by Duo): multifactor authentication and identity intelligence, adding a verification step and device trust signal that other components consume.

Beyond these core five, several supporting products extend visibility and protection without being mandatory for a basic uZTNA deployment. SecureX ties telemetry together across the estate. Umbrella adds DNS-layer protection and secure web gateway functions. Secure Endpoint covers device-level detection and response. Secure Workload extends segmentation into data centre and cloud workloads. None of these replace the core five, but a mature Zero Trust programme tends to pull them in as the architecture matures.

What makes Cisco’s universal ZTNA distinct from a bolt-on ZTNA product is that it combines the cloud control plane (Secure Access) with existing on-premises enforcement (FTD), rather than forcing every packet through a third-party cloud proxy. This matters for organisations that already have Secure Firewall deployed: the access control investment is extended rather than replaced. It also explains why version alignment between Secure Access, Secure Client, FMC and FTD is non-negotiable, a single mismatched component breaks the token exchange that the whole model depends on.

For teams comparing access management options, our walkthrough on Cisco Access Manager covers how Secure Client enrolment and access policy enforcement work together in more operational detail.

How universal ZTNA works: architecture and traffic flow

Universal ZTNA (uZTNA) is best understood as a sequence of trust checks rather than a single gate. Each stage either grants a narrower scope of access or routes traffic to a different enforcement point depending on where the user is connecting from.

An administrator onboards Secure Access and Firewall Management to Security Cloud Control, establishing the cloud side of the control plane.
Secure Client on the endpoint establishes a mutual TLS session with Secure Access, proving device identity before any application access is considered.
Secure Access evaluates the device and user context and issues an access token scoped to the specific private resource being requested.
Secure Client, or the ZProxy component, presents that token when connecting to the FTD enforcement point, which validates it before allowing traffic through.
Trusted Network Detection determines whether the user is on a trusted internal network or remote. On a trusted network, enforcement happens locally on FTD; remotely, traffic is steered through the cloud proxy first.
Where the access token signals that deeper inspection applies, FTD applies IPS, file and malware policies to the session rather than treating it as a simple pass-through.

This split matters operationally. According to Cisco’s configuration documentation, traffic steering and token validation between ZProxy and the Snort inspection engine are designed so that local traffic avoids unnecessary round trips to the cloud, which keeps latency down for users working from managed sites. Remote users accept a small latency cost in exchange for consistent policy enforcement regardless of location.

Pro Tip: Map out which applications genuinely need private, token-gated access before you enable uZTNA broadly; treating every internal service as equally sensitive slows enrolment and makes policy troubleshooting harder than it needs to be.

Latency and inspection depth are the two variables worth testing early. A resource that stays on-premises and benefits from local FTD enforcement will behave very differently under load to one that routes through the cloud proxy, so pilot testing should include both paths rather than assuming one will represent the other.

Prerequisites, limits and urgent notices to avoid deployment traps

Before any uZTNA configuration begins, version alignment across the stack needs confirming. According to Cisco’s configuration guidance, FMC and FTD must run 7.7.10 or later, FTD devices must be in routed mode, and Secure Client must be at version 5.1.10 or later for universal ZTNA to function correctly.

Software versions: FMC/FTD 7.7.10+ and Secure Client 5.1.10+ are required; anything older will fail token validation or enrolment.
Feature flags: Security Cloud Control requires specific feature flags enabled, often only through a TAC request, before uZTNA options appear.
Mode and clustering: FTD must run in routed mode; some cluster and high-availability configurations are not supported for uZTNA and need checking against the current compatibility matrix.
Known limitations: IPv6 is not supported in current uZTNA deployments, certain site-to-site VPN combinations are excluded, and jumbo frame handling has documented constraints.

One prerequisite often overlooked affects every future deployment: from May 2026, many public certificate authorities will stop issuing TLS certificates that include the Client Authentication Extended Key Usage, according to a Cisco field notice on the change. That shift affects ISE services including pxGrid, IMS and TC-NAC, which rely on that EKU for mutual authentication between ISE and connected systems.

The practical mitigation is to inventory every certificate that depends on Client Authentication EKU now, and choose between renewing early under current CA policy, migrating the affected services to the ISE internal certificate authority, or planning an ISE upgrade to a version that relaxes the import restriction where that is safe to do. Leaving this until closer to the cutover risks a hard outage in posture and policy services that most teams only discover when authentication starts failing.

Implementation checklist: pilot to production tasks

Rolling out Cisco Zero Trust works best as a staged sequence rather than a single cutover. The order below reflects how dependencies actually chain together in a uZTNA deployment.

Inventory certificates and dependent services that rely on Client Authentication EKU, and decide on a renewal or internal PKI path before anything else.
Claim the Security Cloud Control subscription and enable the Secure Access and Firewall Management microapps within it.
Upgrade and validate FMC and FTD to a supported version, confirm FTD is running in routed mode, and enable the licences uZTNA requires.
Define private resources in Secure Access, create posture profiles and access policies, and map those policies through to FTD enforcement.
Deploy Secure Client to a representative device set and enrol them, whether by certificate or SSO flow, then test Trusted Network Detection and failover behaviour on both trusted and remote networks.
Pilot with a small user group, validate telemetry and confirm IPS and file policy application is behaving as configured, and document the runbook as you go rather than afterwards.
Plan maintenance windows for the rollout: enabling uZTNA on an FTD high-availability pair reboots both units, according to Cisco’s configuration documentation, so this cannot happen during production hours without planning.
Define success metrics before full rollout: authentication failure rate, time to provision new access, and reduction in standing VPN sessions are all useful early indicators.

Pro Tip: Run the pilot group through a full working week, not a single day, before judging success. Trusted Network Detection behaviour, in particular, often only reveals edge cases once users move between office, home and mobile connections over several days.

Readers planning a wider segmentation project alongside Zero Trust may also find our guide to Cisco microsegmentation useful, since the two efforts share much of the same policy groundwork. For a broader sequencing view beyond the Cisco-specific steps above, our five-step Zero Trust Network Access guide sets out the standards-based version of this same journey.

Identity and posture integrations: ISE, Duo and common pitfalls

Identity is the layer that makes every other Zero Trust decision possible, and it is also where most early deployments run into friction. Duo typically integrates with ISE through an authentication proxy that punts the authentication request back to ISE, which then returns a decision Duo can act on.

Authentication proxy flow: requests pass from the network device, through the Duo proxy, to ISE, and the response determines whether MFA is triggered.
Policy-set matching: according to Cisco Community guidance, ISE requires an explicit policy set for the proxy’s RADIUS source; without it, requests are silently dropped rather than failing visibly.
Network device entries: every device or proxy source sending RADIUS or TACACS+ traffic needs an explicit entry in ISE; a missing entry is one of the most common causes of unexplained authentication failures.
Certificate dependencies: pxGrid and IMS, which ISE uses for posture sharing and integration with other Cisco security products, depend on the same Client Authentication EKU flagged in the field notice above, so certificate planning and identity integration planning cannot be treated separately.

Pro Tip: Build a separate test policy set in ISE for new integrations rather than modifying production rules directly; it isolates failures to configuration rather than live traffic and makes rollback trivial.

Testing should always include certificate chain validation end to end, not just a successful login. A chain that validates during initial testing but breaks after a CA policy change, the scenario the EKU field notice describes, is the kind of failure that only shows up weeks later if it is not checked deliberately. Our network access controller guide covers the broader NAC configuration patterns that sit alongside this identity layer.

Use cases and business benefits

The business case for Cisco Zero Trust tends to centre on a small set of recurring scenarios rather than abstract security posture improvements.

Hybrid and contractor access: per-application access means a contractor or remote employee reaches only the specific service they need, not the wider network segment it sits in.
Hiding sensitive services: internal applications that previously sat on a routable network segment can be made invisible to unauthenticated discovery entirely.
Replacing legacy VPN: moving away from broad VPN access reduces the lateral movement a single compromised credential or device enables, and simplifies access governance because policy is defined per application rather than per network zone.
Integrated detection and response: because ISE, Secure Access and FTD share telemetry, a posture change or threat signal in one system can influence access decisions enforced in another.

The common thread across these cases is a reduced blast radius when something does go wrong, and faster provisioning when something changes, a new contractor, a new application, a revoked device, because access is defined by policy rather than by network topology.

Re-Solution perspective and proof points

Zero Trust programmes succeed or stall based on how well identity, certificates and network enforcement are sequenced, not on how many products are purchased. We have spent more than 35 years working with Cisco infrastructure, and the pattern that holds up across sectors is to audit before you pilot, and pilot before you commit to a managed rollout.

A sensible audit focuses on four things: certificate inventory against the EKU changes, ISE posture readiness, existing network segmentation, and FTD version and licensing readiness. Skipping any one of these tends to surface as a production incident rather than a planning conversation.

This sequencing, audit, pilot, managed rollout or Network as a Service, keeps the scope of each stage manageable and gives decision-makers a clear point to stop, adjust, or proceed before further investment.

— Jacob

How Re-Solution can help: services and next steps

Every stage of the checklist above maps to something we can run directly. Our Network Audits cover certificate inventory, ISE posture readiness and segmentation assessment, which is exactly the groundwork a Zero Trust migration needs before any configuration work starts. Where wireless coverage affects endpoint enrolment and Trusted Network Detection accuracy, our Wireless Surveys identify gaps before they become authentication problems.

For the build and pilot stages, our Professional Services team can configure FMC, FTD and Secure Access to the version and licensing requirements covered above. Once a pilot proves out, ongoing operation sits well under either our Managed Services or, for organisations that prefer subscription-based delivery, our Network As A Service plan.

The practical next step is a readiness review: a short, focused audit that tells you exactly where your certificates, identity systems and firewall estate stand against the prerequisites above. Get in touch to arrange one.

FAQ

What is Cisco zero trust?

Cisco Zero Trust is an identity-first security architecture built from integrated components, including universal ZTNA, Secure Access, Secure Client, Secure Firewall Threat Defense and Identity Services Engine, that grant per-application access rather than broad network trust. It follows the principles set out in NIST SP 800-207, requiring continuous verification of users and devices before access is granted.

Is Cisco ISE zero trust?

Cisco ISE is not Zero Trust on its own; it is the identity, posture and policy orchestration component that a Zero Trust architecture relies on. It works alongside Secure Access, Secure Client and Secure Firewall to make the access decisions that enforce least-privilege principles.

What does zero trust mean in networking?

In networking, Zero Trust means no user, device or request is trusted by default regardless of whether it originates inside or outside the network perimeter. Access is granted per session, to a specific resource, based on continuous verification, following the model defined in NIST SP 800-207.

Who are the top zero trust vendors?

Zero Trust is offered by several major networking and security vendors, each with their own architecture and product mix, so the right choice depends on existing infrastructure and operational requirements. Organisations already running Cisco Secure Firewall and identity infrastructure typically find Cisco’s universal ZTNA the most direct path, since it extends investments already in place rather than replacing them.

Sources

For verification and deeper configuration detail, the following references cover the principles and specific technical steps discussed above. NIST SP 800-207 remains the definitive standard behind Zero Trust terminology and tenets. Cisco’s universal ZTNA solution guide and its Secure Access configuration documentation set out the exact prerequisites and steps for deployment. The Client Authentication EKU field notice is essential reading for any team running ISE, given the May 2026 certificate authority changes it describes. These sources are worth bookmarking before starting configuration work rather than referring to after something breaks.