Zero Trust Adoption Roadmap for Regulated Industries

A technology company with no regulator to answer to can roll out Zero Trust at its own pace, phase by phase, quarter by quarter, until the architecture is clean. A bank cannot. For regulated organizations, the question is not whether to adopt Zero Trust but how to sequence adoption under external deadline pressure, while still running legacy infrastructure that was never built to be segmented, monitored, or governed this way. Most organizations treat Zero Trust as essential, and only a small fraction have fully implemented it, but the organizations in finance, healthcare, and defense stuck in that gap are stuck on someone else's clock, not their own. Adoption rates by sector tell the same story from a different angle: financial services, under SOX, GLBA, and PCI, leads; healthcare, under HIPAA, follows; manufacturing lags because its operational technology environment has no comparable hard mandate forcing the issue. Deadlines move the needle. Risk awareness alone, historically, has not.

What keeps regulated organizations stuck in the prolonged middle state

Intent is not the bottleneck. Security leadership in regulated sectors generally knows Zero Trust is the correct direction, and most have already started. The obstacle is a specific set of execution bottlenecks that compound each other once an organization tries to move past the pilot stage, and the largest of them is tool and vendor sprawl: it is the top cited barrier to adoption, ranking above budget constraints and legacy technology, with 78% of organizations managing secure-access policies across more than two separate systems, producing inconsistent enforcement and duplicated effort across teams that are nominally working toward the same architecture. Running VPN and ZTNA side by side during the transition multiplies that sprawl rather than resolving it: duplicated policies, fragmented tooling, and heavier operational overhead, with nearly half of organizations reporting significant difficulty managing that coexistence period. Legacy infrastructure compounds the problem. Financial services and healthcare both run transaction-critical systems and unmanaged IoMT devices, and these cannot be re-platformed on a compliance sprint's timeline without risking the operations the compliance mandate exists to protect. Staffing the transition is its own separate crisis: a global cybersecurity skills gap has left SASE roles among the hardest to fill anywhere in the industry, largely because formal training curricula have not caught up to how fast the product category has moved, leaving regulated teams unable to staff the transition from inside the building.

Phase 1: Identity and access management as the non-negotiable starting point

Every credible Zero Trust framework, from NIST SP 800-207 to CISA's maturity model to what works in practice, starts in the same place: identity, because it is the only control plane that behaves consistently across cloud, on-premises, and hybrid environments at the same time. Real-world implementations bear this out. The identity-first approach and the access-first approach together dominate real-world implementations, and third-party and contractor access is implicated in a large share of breaches, making IAM the highest-impact starting point. NIST SP 800-63-4, finalized in July 2025, formalized FIDO2 passkeys as eligible for Authenticator Assurance Level 2, removing a major barrier to enterprise-scale phishing-resistant MFA, giving regulated organizations that have been deferring passwordless rollout a clear compliance pathway. Concrete deliverables in this phase: deploy a modern identity provider, enforce MFA across all applications, implement SSO to reduce credential sprawl, and set FIDO2/passkeys as the target end state.

The Microsoft Midnight Blizzard breach, disclosed in January 2024, shows what happens when this phase is skipped. Russian state-sponsored attackers used a password spray attack to compromise a legacy test account that had no MFA on it, then pivoted into the corporate environment through a legacy OAuth application that carried elevated permissions, and they stayed undetected for roughly six weeks. One account, overlooked and operating outside Zero Trust policy, was the entire attack vector. For regulated organizations, identity governance carries a second payoff beyond security: it generates the access logs, policy enforcement records, and privilege attestations that compliance frameworks demand as documented evidence, not as a security nicety but as the paperwork an auditor will actually ask to see.

Phase 2: Replacing VPN with ZTNA and imposing network micro-segmentation

Phase 2 is where most programs stall, because it requires running two network architectures at once without either one degrading the other. ZTNA grants access at the application level rather than the network level, so one compromised VPN credential can no longer reach everything behind it on a flat network, and this directly addresses lateral movement, the attack technique that turned the Midnight Blizzard credential into weeks of access. The 2026 adoption data shows the access-first approach, replacing VPNs with ZTNA for remote and third-party connections, winning out for a specific reason: third-party and contractor access accounts for a disproportionate share of breaches, making this the highest-leverage network control available to regulated organizations managing external auditors, contractors, and supply-chain partners. Micro-segmentation handles the rest, isolating workloads so a compromised device cannot wander into data outside its authorized segment. In healthcare that means you keep IoMT devices walled off from clinical records systems; in financial services it means you keep transaction processing separate from the general enterprise network.

None of this is comfortable to run in parallel. Nearly half of organizations report significant difficulty operating VPN and ZTNA at the same time, and legacy VPNs still account for 41% of company usage according to the Tailscale State of Zero Trust report, so duplicated policy sets sit on top of each other for longer than anyone would like. The fix is a defined VPN sunsetting schedule that retires third-party access first, because that population carries the highest risk, and moves internal users last. Both of the major compliance frameworks expect this phase to be documented, not just completed: M-22-09's network pillar and NIS2's access control obligations both map directly onto ZTNA and segmentation, so organizations should keep deployment scope and segmentation boundaries on file as evidence artifacts for the next compliance review.

Phase 3: Continuous monitoring, adaptive policy, and device trust

Identity controls and ZTNA, even implemented well, are static by design. They check once per session unless you build something on top to keep checking. That is insufficient once the threat environment includes behavioral attacks and insider risk, and the compliance frameworks that require continuous monitoring expect this phase to be running in production, not sitting in a roadmap deck. Continuous authorization evaluates access before, during, and after a session rather than only at login, weighing identity, device posture, session behavior, location signals, data sensitivity, and live threat intelligence together. This is the phase where Phase 1's work pays off: continuous monitoring is only as good as the identity signal feeding it, and an organization that built a clean identity fabric in Phase 1 has something consistent to analyze in Phase 3.

Device trust belongs in this phase too, and skipping it undermines everything built before it. The UK NCSC's architectural guidance treats users, devices, services, data, identities, behavior and health assessment, policies, authorization, monitoring, network trust, and zero-trust-ready services as concerns addressed across eight design principles, and unvalidated endpoint posture is a common gap that renders otherwise solid identity controls partially ineffective. User and entity behavior analytics supplies the adaptive mechanism: a session showing impossible travel, an abnormal volume of file downloads, or suspicious admin activity can trigger a step-up authentication challenge, a restriction on access, or an outright session termination, and auditors increasingly expect to see this kind of adaptive response as proof that monitoring is actually continuous. Adaptive, trust-based WAF and access policies apply the same logic at the network layer: they scale scrutiny to perceived risk, so trusted users get less friction while anomalous behavior gets hardened against. For regulated industries the dividend compounds: the logs this phase generates become the audit trail that satisfies SOX, HIPAA, and NIS2 documentation requirements, so the security investment produces compliance evidence as a side effect rather than a separate project.

Phase 4: Data protection and sovereign SASE as the compliance end-state

Data is the hardest phase, and it is hard for a structural reason: it requires rebuilding how data is stored, labeled, and governed rather than adjusting who can reach it. For organizations under GDPR, NIS2, and the EU AI Act, it additionally demands proof of where data gets inspected and decrypted, not merely confirmation that it is encrypted somewhere. The deliverables are unglamorous but non-negotiable: DLP policies, encryption at rest and in transit, a working data classification system, and defined data residency controls, all of which require real changes to data architecture rather than another layer of access policy bolted on top.

This is where sovereign SASE earns its place in the roadmap, because it answers a question the first three phases cannot. GDPR and NIS2 apply serious regulatory pressure on where personal data gets processed and stored, and the EU AI Act layers on data governance and logging obligations for high-risk AI systems, and together these three regulations push organizations toward architectural decisions about where processing physically happens, even though none of them explicitly names a required geographic location for traffic inspection or decryption. Organizations need assurance that policy enforcement and logging actually occur inside defined geographic boundaries, beyond a general assurance that encryption exists somewhere in the pipeline. A unified global network built to enforce policy by geography, rather than merely route traffic through it, is the concrete infrastructure answer to that demand: regulators are no longer satisfied by "it's encrypted," they want to know where the enforcement point physically sits. Sovereign SASE has moved from a niche procurement line item to a board-level agenda item as scrutiny of data flows has intensified, because it is the architectural answer to the exact question compliance officers and data protection authorities are now asking. The convergence model that defines this phase, SD-WAN, SSE, and policy management folded into a single agent and console, resolves the tool sprawl identified back in the diagnostic section as the roadmap's original barrier, so the architecture that closes the roadmap is the same one that fixes the problem that opened it.

Non-human identities and AI agents as the compliance gap that the standard roadmap misses

The four-phase model above is built on NIST's architecture, and NIST's architecture assumed that the identities doing the requesting were human. That assumption is now wrong often enough to matter. Governing AI agents and non-human identities is the fastest-growing Zero Trust use case inside regulated environments, one the standard frameworks were not built to handle. A large majority of security professionals report concern about the impact of AI agents on security, and organizations deploying agents without non-human-identity controls are piling up compliance exposure ahead of a mandate cycle that has not caught up yet. The mechanism is straightforward and underappreciated: AI agents create non-human identities that can query databases, call APIs, update records, and trigger workflows, frequently carrying privileges that exceed the authority of the humans who built them, all without the lifecycle controls, onboarding, offboarding, periodic review, that a human account automatically gets. An intern gets deprovisioned the day they leave. An orphaned service account with admin rights can run for years.

A very large share of organizations that have already had an AI-related security incident lacked proper AI access controls at the time, and a majority had no AI governance policy in place at all, which indicates the exposure is a systemic feature of how agents get deployed, present across many companies rather than isolated to a handful of unlucky ones. The market has priced this in: the non-human-identity access management market is already valued at substantial scale in 2026 and is projected to grow significantly by 2036, which reflects an industry-wide recognition that NHI governance is its own distinct problem, not a feature extension of existing IAM tooling. Only a small fraction of companies have fully operationalized responsible AI practices today, and the ones governing non-human identities now are building the audit trail and policy infrastructure that the next wave of mandates, likely arriving on the back of the EU AI Act's enforcement ramp, will require them to produce. Building this before the mandate exists is cheaper than building it after an auditor asks for it.

Sequencing the roadmap by compliance mandate

No single sequence fits every regulated sector, because the deadlines and the data at risk are not the same across SOX, HIPAA, NIS2, and DoD supply-chain requirements. A defense contractor racing the FY 2027 deadline should treat ZTNA's network pillar requirements and access control obligations as priorities to document, with micro-segmentation boundaries and deployment scope serving as evidence artifacts for compliance reporting. For a financial services firm under SOX, GLBA, and PCI, continuous monitoring logs become the audit trail that satisfies SOX documentation requirements, with the security investment producing compliance evidence as a byproduct. Legacy infrastructure in healthcare includes unmanaged IoMT devices that cannot simply be re-platformed during a compliance sprint, so a healthcare organization under HIPAA should front-load micro-segmentation that isolates IoMT devices from clinical records systems. Any organization operating in the EU under NIS2 and the EU AI Act should not wait for Phase 4 to think about sovereign SASE or for some future phase to think about non-human identities. The mandate sets the clock. The phases do not change. Only the order in which an organization runs toward them should.