Zero trust gap assessment: what your ZTA implementation is actually missing
Amara OkaforApril 29, 2026
Key takeaways
Device posture enforcement is the most commonly broken zero trust control: in Vulnox assessments, over 60% of organizations claiming ZTA maturity had at least one privileged access path with no functioning posture check.
NIST 800-207 compliance and zero trust maturity are not the same thing. An environment can satisfy every documented control requirement while enforcing almost none of them in practice.
The identity pillar gets over-invested in while the data pillar gets ignored. Application-layer access policies do not protect data stores when a compromised application account has full dataset access.
Micro-segmentation gaps are invisible to vulnerability scanners because they are policy drift, not misconfigurations. You find them by tracing access paths, not running port scans.
A zero trust gap assessment on a flat-network environment with documented ZTA policies will almost always find east-west movement between 20 or more internal segments that the architecture diagram says should not communicate.
Repeating a zero trust gap assessment annually is not overcaution. Control drift from cloud workload changes, credential rotation failures, and device enrollment gaps means the findings change significantly within 12 months.
TL;DR
Zero trust architecture fails most organizations not at design but at enforcement. The gap between documented ZTA policy and what actually runs on the network is where attackers operate. Most zero trust gap assessments stop at the framework checklist. The ones that find real problems trace actual access paths, test whether device posture checks are enforced or advisory, and map what a compromised session can reach after authentication succeeds. That is a different exercise. This article explains what those assessments actually find.
The audit said zero trust. The assessment said otherwise.
A 200-person SaaS company completed an 18-month zero trust rollout. They had a named framework, NIST 800-207. They had a compliance audit that signed off on IAM, MFA, and network segmentation documentation. Their CISO described the project as done. Three weeks into a Vulnox assessment, we had mapped 34 east-west communication paths between segments their architecture diagram showed as isolated. Device posture enforcement was deployed across 80% of endpoints but set to report-only on the remaining 20%, which happened to include every privileged workstation used by the infrastructure team. The compliance audit never touched enforcement status. It reviewed policy documentation. Those are not the same artifact.
The failure was not that they had implemented zero trust badly. It was that no one had assessed whether implementation matched documentation. The architecture existed. The enforcement did not. A zero trust gap assessment that only reviews framework alignment against documented controls will miss this every time.
What zero trust gap assessment actually measures
A zero trust gap assessment has two distinct phases that most engagements collapse into one. The first is framework alignment: does your documented control set cover the five NIST 800-207 pillars — identity, devices, networks, applications, data? Most organizations can satisfy this phase with policy documentation and architecture diagrams. It is the easier part.
The second phase is enforcement validation: are the controls that exist on paper functioning under realistic access conditions? This requires testing. Device posture checks need to be validated against actual enrollment completeness, not enrollment reporting. Network micro-segmentation needs to be tested against real traffic paths, not firewall rule documentation. Policy enforcement at the application layer needs to be verified against service account permissions, not just user-facing access controls.
The gap between these two phases is where zero trust implementations collapse. Organizations invest heavily in phase one because auditors check it. Phase two requires hands-on technical work that most compliance-driven assessments never do.
Example
In one financial services assessment, the client had documented continuous verification across all access paths. The actual verification logic was conditional on device enrollment status. Service accounts, which handled all API calls between internal systems, were excluded from the enrollment requirement because the team that built the integration could not get the agent to run on the container runtime. Exclusion was documented as a temporary exception two years earlier. It was never reviewed. Those service accounts had access to payment processing APIs with no posture check, no session timeout, and no anomaly detection. The zero trust architecture was real. That path was outside it.
The failure mode here is not rare. Service accounts, legacy systems, and container workloads are the three consistent exclusion categories in zero trust deployments. Each is excluded for a legitimate operational reason at deployment time. None are reviewed systematically after exclusion. A gap assessment that does not enumerate these carve-outs will systematically undercount enforcement gaps.
What we found across ZTA assessments
Assessment base: Vulnox assessment data, 2024-2025, across ZTA-claiming environments in financial services, SaaS, and healthcare verticals.
Device posture enforcement is advisory, not blocking, on 20-40% of enrolled endpoints
Across assessments where clients reported full device posture deployment, we consistently found a fraction of the endpoint population where posture checks were set to report-only mode. The reason is always the same: enforcement mode generated help desk volume during rollout, was temporarily relaxed, and was never re-enabled. The excluded endpoints trend toward privileged access workstations, developer machines, and infrastructure management hosts — the highest-value targets.
The client believed posture enforcement was complete. It was complete by enrollment count. It was not complete by enforcement status. Those are different metrics. A gap assessment that queries enrollment numbers will miss this. One that tests whether a non-compliant device can authenticate and what it can reach will find it immediately.
East-west movement between documented micro-segments is unrestricted in the majority of assessed environments
When we trace traffic paths between segments that an architecture diagram shows as isolated, we regularly find that the firewall rules or security group policies implementing that isolation are incomplete. Cloud workload migrations are the leading cause: teams migrate a workload and inherit the source environment's security group rather than building a new one aligned to the zero trust policy. The workload sits in the right segment on the diagram and the wrong policy in the actual enforcement layer.
Micro-segmentation is the zero trust control most organizations think they have and least organizations have enforced correctly. The diagram is not the control. The ACL is the control. These need to be validated against each other, not assumed to match.
Data pillar controls stop at the application layer in almost every assessed environment
NIST 800-207 treats data as a distinct pillar requiring its own access controls, not just controls inherited from the application above it. In practice, organizations build strong application-layer access controls and assume data-layer protection follows. It does not. A compromised application service account typically has read access to full datasets because the data store access policy was never scoped. The application controls the query. Nothing controls what the application can query.
When we demonstrate this finding to clients, the consistent response is that data-layer access controls were in scope for a future phase. That future phase arrives after a breach, not before one. The data pillar gap is structural and it is not addressed by NIST 800-207 compliance documentation that checks policy existence rather than enforcement depth.
The more mature the ZTA documentation, the larger the enforcement gap tends to be
Common belief
Organizations with detailed zero trust architecture documentation, named frameworks, and completed compliance audits have stronger enforcement than organizations with less formal programs.
What we found
In a healthcare client assessment, the ZTA documentation ran to 340 pages and had been reviewed by an external auditor six months prior. The audit found two low-severity findings. Our assessment found 18 enforcement gaps, including three service account paths into the clinical data environment with no posture check, session control, or anomaly monitoring. The audit reviewed what was documented. We tested what was running.
The opposite pattern appears in our data. Organizations that invested heavily in ZTA documentation and compliance audit readiness consistently show larger gaps between documented controls and enforcement reality than organizations with less formal programs. The mechanism is not complicated: formal programs create structured exemption processes. Every exception to enforcement policy gets documented and approved rather than escalated for resolution. The documentation grows cleaner while the enforcement landscape grows more fragmented. Auditors review documentation. They do not trace access paths.
Organizations without formal programs often have fewer, simpler controls that are actually enforced because no one built an exception process for them. The controls that exist, work. The coverage is narrower but the depth is real.
Where zero trust gap assessments consistently miss
Container and serverless workloads
Zero trust agent deployment requires a persistent runtime. Containers and serverless functions frequently cannot run agents, do not maintain session state, and are exempt from posture enforcement at deployment. The exemption is logical. The problem is that these workloads often handle the most sensitive operations — payment processing, credential validation, data transformation — and their east-west access is governed by cloud IAM roles that predate the zero trust deployment. No one re-scoped the IAM roles when the zero trust policy was written. The workloads communicate freely across policy boundaries because they were never enrolled in them.
Third-party access paths
Zero trust implementations focus on internal users and managed devices. Third-party access — vendors, contractors, integration partners — typically runs through separate paths: VPN, jump hosts, or direct API keys that were provisioned before the zero trust rollout and never migrated. These paths bypass every posture check and session control in the ZTA deployment. They are often the highest-privilege paths in the environment because they were provisioned by teams with admin access who took the shortest route. A gap assessment that limits scope to internal users will not see them.
Authentication success as a false floor
Zero trust verification logic in most deployments runs at authentication time. If authentication succeeds and the session passes initial posture checks, the session is typically trusted for its duration. What happens after session establishment — what the authenticated session can reach, what it can query, how far it can move — is the enforcement layer that most implementations do not build. The attacker who steals a valid session token gets exactly what the legitimate user gets. Continuous verification as NIST 800-207 describes it means re-evaluating trust during the session, not only at the start. Most implementations do not do this.
Where zero trust gap assessment is heading
By 2027, cloud-native workload exclusions from zero trust enforcement will be the primary breach entry point in organizations that have completed formal ZTA deployments, displacing credential phishing as the leading initial access vector in that population.
As MFA and conditional access mature across user populations, attackers adapt toward the paths that bypass those controls. Container workloads, serverless functions, and CI/CD pipelines are systematically excluded from ZTA enforcement because the architecture cannot accommodate them. These paths are already used in targeted intrusions. As ZTA user-facing controls harden, the relative value of these exclusions increases. The signal to watch is the ratio of initial access via compromised user credentials versus compromised service account or workload identity in breach disclosures from organizations with documented ZTA programs.
Confidence: highBreach disclosure data from organizations with audited ZTA programs showing initial access vector distribution in 2026-2027 reports.Zero trust gap assessment will split into two distinct service categories within three years: compliance alignment assessment (framework documentation review) and enforcement validation assessment (technical control testing). Organizations will increasingly need to purchase both separately because the skills required do not overlap.
The current market conflates these under a single service label. Compliance alignment is a policy and documentation review exercise. Enforcement validation requires hands-on technical work: tracing access paths, validating posture check behavior, testing session controls. The practitioners who do one well rarely do the other well. As buyers become more sophisticated and breach disclosures increasingly show the gap between documented compliance and enforcement reality, demand for explicit enforcement validation will separate from the compliance review market.
Confidence: mediumEmergence of distinct service line pricing and scope descriptions for the two categories in major security vendor service catalogs by 2028.
NIST 800-207 is a useful architecture reference and a poor assessment framework
NIST 800-207 does what it sets out to do: describe what a zero trust architecture should contain. It is not designed to tell you whether your implementation is enforcing those controls in practice. Using it as the primary assessment framework produces clean compliance documentation and persistent enforcement gaps. Most zero trust gap assessments are run against 800-207 because it is the named framework. That is the wrong question to be answering with an assessment. The right question is whether an attacker who authenticates successfully can move where they should not be able to move. 800-207 does not have a test case for that.
Counterargument
The counterargument is that NIST 800-207 provides the only widely accepted vocabulary for zero trust architecture evaluation, and that enforcement validation without a framework produces inconsistent, non-comparable results. That is a fair point. Framework-based assessments produce results clients can benchmark and explain to boards. The problem is not using 800-207. The problem is stopping there and treating framework alignment as the primary deliverable. Use 800-207 for structure. Test enforcement independently. The two outputs need to coexist in the same assessment report.
One thing to do this week
Pull the exceptions list from your zero trust policy documentation. Every service account, legacy system, or workload that was excluded from posture enforcement at deployment with a documented exception. Count them. Then pick three at random and trace what they can reach in your environment. Not what the documentation says they can reach. What they actually can reach, based on the firewall rules or security group policies currently in effect. If the answer surprises you, you have a gap assessment finding. If it does not surprise you, you either have a very mature enforcement environment or you have not looked carefully enough. Either way, you now know something about your zero trust posture that your last compliance audit did not tell you.
Further Reading
Gap Analysis
framework gap analysisNIST
NIST framework questionnaireNational Vulnerability Database NIST
NIST National Vulnerability DatabaseNIST Cybersecurity Framework 2.0
NIST Cybersecurity FrameworkCybersecurity Gap Assessments
cybersecurity gap assessments
Frequently Asked Questions
What does a zero trust gap assessment actually find that a standard vulnerability scan misses?
A vulnerability scanner checks for known CVEs and misconfigurations on reachable services. A zero trust gap assessment evaluates whether your continuous verification controls actually function under real access conditions — device posture checks, lateral movement constraints, policy enforcement at the application layer. In our assessments, these are frequently documented on paper but not enforced in practice, especially for service accounts and legacy systems excluded from MFA rollouts.
How does NIST 800-207 define the five pillars of zero trust and what do most organizations get wrong?
NIST 800-207 structures zero trust around identity, devices, networks, applications, and data. Most organizations reach moderate maturity on identity and network pillars because those map to existing IAM and firewall investments. The consistent failure points are device posture (enrollment is incomplete, compliance checks are advisory not enforced) and data (access policies exist at the application layer but not at the data store level, meaning a compromised app account gets full dataset access).
What is the difference between zero trust architecture maturity and zero trust compliance?
Compliance means your documentation, policies, and selected controls map to a framework like NIST 800-207. Maturity means those controls are enforced continuously and degrade gracefully under failure conditions. We have assessed environments with clean zero trust compliance documentation where device posture enforcement was disabled on 40% of endpoints because it caused help desk tickets. That gap does not show in audit reports.
How long does a zero trust gap assessment take and what should it produce?
A credible assessment takes three to six weeks depending on environment size. It should produce: a pillar-by-pillar maturity score against a named framework, a prioritized gap list with exploitation paths not just control descriptions, evidence artifacts showing which controls were tested and how, and a phased remediation roadmap with quick wins separated from structural changes. Anything shorter than this is a questionnaire review, not an assessment.
What is the most common ZTA implementation mistake organizations make after an assessment?
Treating identity as the only pillar that matters. Organizations deploy strong MFA and conditional access, then declare zero trust done. The network layer still allows broad lateral movement once a session is authenticated. In several engagements we mapped authentication paths that successfully verified identity but then permitted east-west traffic between 30 or more internal segments with no additional enforcement. The attacker gets in legitimately and moves freely.
How does micro-segmentation work in a zero trust gap assessment and what does failure look like?
Micro-segmentation assessment maps the actual enforcement boundaries between network segments and compares them to the documented policy. Failure looks like: segments defined in the architecture diagram that do not exist as enforced ACLs or firewall rules; service accounts with access to multiple segments for operational convenience that were never reviewed post-deployment; and cloud workloads that inherited permissive legacy security groups when migrated. These are not configuration errors caught by scanners — they are policy drift that only becomes visible when you trace specific access paths.
Related Articles
GovRAMP Moderate authorization: why the Significant Change Request process catches providers off guard
GovRAMP Moderate is the first tier where you need a government sponsor, annual 3PAO reassessment, and a Significant Change Request process that can pause normal product releases for months. Most providers who stall post-authorization were not prepared for what maintaining Moderate status actually costs operationally.
GovRAMP Low+ authorization: the impact level that punishes providers who get the CUI boundary wrong
GovRAMP Low+ is where providers handling limited Controlled Unclassified Information land — or discover they should not be there. The defining failure is not a missing control. It is a CUI boundary that was drawn before anyone asked what data the government actually sends through the system.
GovRAMP High authorization: why FIPS-validated crypto and personnel security controls catch providers off guard
GovRAMP High is where cloud providers discover that having strong encryption is not the same as having FIPS 140-2 validated encryption — and that distinction alone has derailed authorizations from vendors who passed every other control family. The architectural constraints at High are qualitatively different from every lower tier.
Ready to Secure Your Digital Assets?
Get a comprehensive vulnerability assessment for your website today.