By Michael Henry, CEO, Accelerynt
Everyone says Zero Trust fails at enforcement. In practice, it breaks much earlier – and the reason is more embarrassing than most security leaders want to admit.
The audit cycle owns the foundation of most Zero Trust programs – and the audit cycle doesn’t care about your threat environment. The auditor showed up, a consultant produced the asset inventory, the compliance box got checked – and Discovery stopped. The report got filed. The program got built on that snapshot. And the environment kept moving.
That was probably fourteen months ago.
Which means the thing your Zero Trust program is built on runs on a schedule set by regulators – not by your threat environment. New devices, cloud workloads, shadow IT, personnel changes – none of that paused while you waited for the next audit cycle.
Audits are annual. Threats aren’t.
Why the Cadence Is the Problem
Zero Trust demands continuous verification. But most security teams inherited a Discovery process built for a different purpose entirely – producing a point-in-time assessment that satisfies a compliance requirement.
Auditors set the cadence. Security teams responded to it. That made sense when Discovery was a compliance deliverable. It stops making sense when Discovery is supposed to be the operational foundation of your entire security program.
The result is a program built on a snapshot that starts aging the moment the audit closes. New devices come online. Cloud configurations drift. Personnel changes create access exceptions. Shadow IT expands. None of it shows up in the baseline until the next audit cycle forces another look.
Gartner found that 35% of Zero Trust implementations failed in ways that adversely impacted operations. The most consistently cited root cause: foundational gaps in identity and asset management. Kindervag, who invented the Zero Trust framework, said it explicitly in 2024 – solid asset and identity management foundations have to exist before Zero Trust can function. That’s Discovery. The thing the compliance calendar produced once and the security team hasn’t owned since.
Tailscale’s 2025 survey of 1,000 security professionals found that 29% of organizations only change their security approach when a compliance requirement or audit finding forces it. Another 38% are waiting for a major breach. Between those two triggers, most organizations have effectively outsourced the Discovery cadence – either to the auditor or to the adversary.
This isn’t a new problem. CIS has listed asset inventory at the top of its critical security controls for years – not because it’s technically difficult, but because organizations consistently fail to maintain it. The audit cycle is why. When the only forcing function is annual, the inventory is annual.
What Running This Inside Real Environments Taught Us
When we built continuous assessment into real Microsoft tenant environments, we expected to find gaps. What we didn’t expect was how consistently security practitioners were surprised by what we found.
Experienced practitioners. Teams that know their environments. The gap shows up anyway.
Two findings appear with enough consistency that we treat them as baseline assumptions going into every engagement.
The first: services running that the security team didn’t know were active. Live, accessible, and outside the perimeter the team believes they’re defending. The Zero Trust policy is enforcing rules against a map that doesn’t include them.
The second: configuration changes that happened outside the approval process. The baseline was set, the program was built on it, and somewhere between the last audit and today the environment drifted. The changes aren’t always malicious. But they’re real, untracked, and weakening a baseline the security team believes is intact.
What makes both findings significant is that experienced practitioners didn’t know they existed. The confidence was genuine. The gap was real. And the existing process had no mechanism to surface it between audit cycles.
The environment doesn’t hold still. The baseline shouldn’t either.
Three Moves That Shift Discovery From Audit Deliverable to Operational Practice
- Measure the age of your baseline.
Pull your current asset inventory and configuration baseline. Note when it was last updated and what triggered the update. For most organizations that answer points directly to the last audit cycle.
The gap between that date and today is the window of unverified drift. You don’t need to close it immediately – but you need to know how wide it is before you can make an honest assessment of where your Zero Trust program actually stands.
That single measurement changes the conversation inside the security team. It turns “we have a baseline” into “we have a baseline that’s fourteen months old” – and those are different security postures. - Establish drift detection against the approved baseline.
A baseline is a claim about what your environment looks like at a point in time. Drift detection is the mechanism that tells you when that claim is no longer true.
This means defining what the approved state looks like – which services should be running, which configuration settings should be in place, which changes require approval – and then measuring continuously against it. When we do this inside Microsoft tenant environments, two things surface consistently:
services running that weren’t expected, and configuration changes that happened outside the approval process.
Both were invisible to the security team until something was measuring for them.
Drift detection doesn’t require a full platform overhaul to start. It requires a defined baseline and something continuously measuring against it. Start narrow – a single workload, a single configuration domain – and expand as the process matures. - Build a response to drift, not just detection of it.
Detection without a defined response is a monitoring dashboard. It produces signal. It doesn’t produce security.
When drift surfaces – an unapproved configuration change, an unexpected service, an access exception that wasn’t approved – the security team needs a defined answer to three questions: who owns the remediation, what’s the expected response time, and what’s the escalation threshold if it isn’t addressed.
Without those answers, drift findings accumulate. Teams deprioritize them. The signal becomes noise. And the baseline continues to erode in plain sight.
The response process doesn’t need to be complex. It needs to exist, be owned, and be practiced before an incident demands it.
The organizations that treat Discovery as a continuous operational practice will build Zero Trust programs that actually reflect their environments. Their policies will enforce against accurate maps. Their baselines will mean something. When drift occurs – and it will – they’ll know within days, not at the next audit cycle.
The organizations that don’t will keep building on snapshots. The program will look mature from the outside. The compliance report will confirm it. And somewhere in the gap between the last audit and the next one, the environment will drift in ways nobody is measuring – services running that shouldn’t be, changes accumulating against a baseline nobody is watching.
The adversary doesn’t wait for the audit cycle. The question is whether your Discovery process does.