Why Identity Management Gaps Undermine Your Zero Trust

Somewhere in your environment right now, there’s an account nobody remembers creating.

It belongs to a contractor who finished a project in 2023. Or a service account that a former admin set up to move files between two systems. Or a shared login for a vendor portal that three people have used and nobody has changed the password on since it was created.

That account still works. It still has permissions. And if you’ve spent the last two years rolling out Zero Trust, that account is the hole in the middle of everything you built.

Here’s the uncomfortable part: Zero Trust doesn’t fail because the tools are bad. It fails because the identity data underneath those tools is wrong. You can buy the best policy engine on the market, wire it into every application, and still get popped through a login that should have been disabled eighteen months ago. This is what I mean when I talk about identity management gaps — not some abstract governance concern, but the specific, boring, painfully real ways your directory has drifted out of sync with reality.

I’ve watched organizations spend seven figures on Zero Trust architecture while their privileged access review was a spreadsheet emailed around once a quarter and never completed. That’s the pattern. The security spend goes up, the identity hygiene stays flat, and the gap between them is exactly where attackers live.

If you want Zero Trust that actually holds up, you have to fix the identity layer first. Not after. First.

What Identity Actually Means in a Zero Trust Architecture

The phrase “never trust, always verify” gets repeated so often it’s lost most of its meaning. Let’s pull it apart.

Verification requires something to verify against. When a user requests access to a system, your policy engine asks a series of questions: Who is this? What device are they on? What’s their risk score? Is this normal behavior for them? What have they been authorized to do?

Every one of those questions resolves back to identity. If the identity record is stale, the answers are wrong. And when the answers are wrong, “verify” becomes “guess.”

The old perimeter logic and why it broke

For most of computing history, the network was the security boundary. If you were inside the firewall, you were trusted. Access control meant controlling the drawbridge. Once someone was through it, they could wander.

That model fell apart for reasons everybody knows by now. Cloud applications live outside the perimeter. Remote work means employees never touch it. Contractors, partners, and third-party tools need access without being “inside.” And attackers figured out that stealing a credential is far easier than breaking through a firewall.

So the boundary moved. Instead of the network being the perimeter, identity became the perimeter. That’s the whole premise of Zero Trust.

Identity as the new perimeter — but only if it’s clean

Here’s where the analogy gets dangerous. A network perimeter is mostly stable. Firewall rules change slowly. A directory? A directory changes constantly. People join, leave, change roles, get promoted, go on leave, come back, get rehired as contractors, get new devices.

Every one of those events should trigger an identity change. In practice, most organizations handle the “join” part well — IT gets a ticket, the account gets created. It’s the rest of the lifecycle where things fall apart.

The result is a directory that’s technically functioning but factually inaccurate. It reports that you have 1,847 active users when the real number is closer to 1,600. It says a former employee’s account was disabled when it was disabled in one system and left active in four others. It says you have twelve domain admins when nobody can name more than six.

Zero Trust policies built on that data are only as good as the data. Garbage in, garbage policy out.

The Identity Management Gaps That Quietly Break Zero Trust

Let’s get specific. These are the gaps I see most often, roughly in order of how much damage they do.

Orphaned and stale accounts

An orphaned account is one with no identifiable owner — the person left, the department restructured, and the account just kept living. A stale account is one that exists but hasn’t been used in a long time.

Both are problems, and both are shockingly common. In most environments I’ve looked at, somewhere between 5% and 15% of accounts fall into one of these categories. That’s not a rounding error. On a 2,000-user directory, that’s 100 to 300 credentials sitting around waiting to be useful to someone who isn’t you.

Why do they matter for Zero Trust? Because your policy engine treats them as legitimate identities. They pass the “who is this” check. They may pass MFA if the MFA method was enrolled before the person left and never revoked. They may have standing access to systems that no policy ever re-evaluates because nothing about the account looks anomalous — it’s been there for years.

Colonial Pipeline is the example everyone reaches for, and for good reason. The 2021 attack came through a single legacy VPN account. That account was reportedly no longer in active use, but it still worked. It had a password that had leaked elsewhere. There was no MFA on it. One credential, no exploitation of a software flaw, and a fuel pipeline shut down.

That wasn’t a Zero Trust failure in the sense of bad policy design. It was an identity management failure that made every policy irrelevant.

Over-privileged service accounts and permanent admin

Service accounts are the cockroaches of enterprise identity. They survive everything. They’re created for a specific purpose, they often have broad permissions because that was easier than scoping them properly, and their credentials get hard-coded into scripts, config files, and application code where nobody can rotate them without breaking something.

Now add Zero Trust on top. Your policy says access should be granted just-in-time and just-enough. Your service accounts say otherwise. They have standing access, they never re-authenticate interactively, and they often can’t be touched by conditional access policies because the thing using them is a batch job at 2 a.m., not a human with a phone.

Permanent admin rights are a related disease. Someone needed elevated access for a migration, got it, and never gave it back. Multiply that across a few years and a few hundred change requests and you end up with dozens of people holding privileged access they use twice a year.

Credential sprawl and shadow identities

Every SaaS application your company adopts creates another identity store. Your HR platform, your project management tool, your marketing analytics suite, your CI/CD pipeline, your cloud providers. Each one has its own idea of who works at your company.

Then there’s the shadow layer: personal accounts used for work, shared logins for shared tools, API keys pasted into Slack, local accounts created on servers during an incident and never removed.

None of these appear in your central directory. Your Zero Trust policy engine doesn’t know they exist. So they get no policy at all, which is the most permissive state possible.

MGM Resorts in 2023 is a good illustration of where identity gaps lead. The attackers didn’t need a zero-day. They called the help desk, convinced someone to reset credentials, and moved from there. The technical controls were fine. The identity verification process around them wasn’t.

Weak joiner-mover-leaver processes

The joiner-mover-leaver lifecycle is where most identity debt accumulates.

Joiners are usually handled. There’s a ticket, there’s a provisioning workflow, someone creates the account.

Movers are where it goes sideways. Someone moves from finance to product management. Finance access should be removed, product access added. In practice, the addition happens and the removal doesn’t. Three years later, that person has accumulated access from four roles and nobody has any idea why they can see the revenue forecasts.

Leavers are worse. HR notifies IT, IT disables the primary account, and then stops. The person’s account in the CRM, the shared drive, the vendor portal, and the cloud console all stay active. Sometimes nobody notices for years.

MFA gaps and the exceptions nobody tracks

MFA is one of the highest-value controls you can deploy, and it’s also one of the most commonly undermined by exceptions.

• The executive assistant who “can’t” use the authenticator app.

• The legacy application that doesn’t support modern auth, so you set up a bypass.

• The service account you excluded because it broke the nightly job.

• The break-glass account that exists in case SSO goes down.

Each exception was reasonable when someone approved it. Collectively, they form a map of your weakest points. And if that map isn’t written down, reviewed, and time-limited, it becomes permanent infrastructure.

Here’s the Zero Trust twist: your policy engine might see an MFA exception and treat it as a legitimate configuration, not a risk. Unless your policy explicitly says “no access without phishing-resistant MFA, period,” the exception quietly overrides the intent.

Machine and non-human identities

This is the fastest-growing identity category and the one most organizations manage the least.

Think about how many non-human identities exist in a modern environment: service accounts, API keys, OAuth tokens, managed identities, certificates, CI/CD secrets, database credentials, container service accounts, webhook tokens, and so on. In many cloud environments, non-human identities outnumber human ones by a factor of ten or more.

They’re created by developers who need something to work. They’re rarely inventoried. They’re rotated on a schedule that exists mostly in someone’s head. They often have far more permission than the task requires.

If your Zero Trust strategy only covers human users, you’ve covered maybe 10% of your actual attack surface.

Poor visibility into what identity data actually says

You can’t verify what you can’t see. And identity visibility is genuinely hard because the truth is spread across a dozen systems that don’t talk to each other.

Active Directory says one thing. Azure AD or Okta says another. The HR system says a third. The cloud providers each have their own view. Your PAM tool has yet another. Reconciling these into a single accurate picture is a project most organizations keep starting and never finishing.

So people make decisions on incomplete data. An access review gets approved because the reviewer only sees the primary directory, not the eleven SaaS apps where the person also has accounts. A terminated employee’s access gets “removed” because one system was updated.

Why These Gaps Persist (It’s Usually Operational, Not Technical)

It would be comforting to think these gaps exist because the tools aren’t good enough. They mostly aren’t the problem.

The real reasons are operational, and they’re the same reasons over and over.

Security and IT operations work from different lists

Security teams think in terms of risk. Operations teams think in terms of systems that need to keep running.

When security asks for a service account to be scoped down, operations hears “you want to break the billing job.” When operations creates a new account with broad rights to unblock a project, security hears “you just created another unmanaged identity.”

Neither side is wrong. The failure is that there’s no shared process where these decisions get made together. Change management boards approve technical changes without an identity impact review. Security reviews happen in a different meeting with different people and different data.

Change management doesn’t account for identity drift

Every change to your environment — new application, new integration, new cloud subscription, new vendor — creates identities. If your change process doesn’t include a step that asks “what identities does this create, and who owns them,” you’re adding to the pile with every release.

Most change processes don’t ask that question. So identity drift is a byproduct of normal operations. It’s not that anyone is careless. It’s that the process has a blind spot and the blind spot compounds.

Nobody owns “identity hygiene”

Ask who owns identity in your organization and you’ll get several answers. IT owns the directory. Security owns the policy. HR owns the truth about who works there. Application teams own their own user stores. The cloud team owns cloud identities.

Nobody owns the whole thing. Which means nobody owns making the whole thing accurate.

That’s the structural problem. It’s not a technology gap. It’s an accountability gap with a technology symptom.

A Step-by-Step Walkthrough: How One Stale Account Became a Breach

Let me make this concrete with a scenario that isn’t exotic. I’ve seen versions of this play out.

The setup. A mid-size healthcare company, around 3,000 employees, subject to HIPAA. They’ve been rolling out Zero Trust for eighteen months. Conditional access policies are in place. MFA is enforced for all human users. Micro-segmentation is partially deployed. By most measures, they’re doing well.

Day 0 — the account. Three years ago, a database administrator named a contractor to help with a migration. IT created an account in Active Directory with elevated database rights. The contractor finished the work in four months.

The leaver process. The contractor’s manager told HR the engagement ended. HR notified IT. IT disabled the contractor’s main account. But this particular account was created under a slightly different name — a naming convention that predates the current standard — and the ticket only listed the primary account.

Day 1 to Day 1,000 — nothing happens. The account sits there. It doesn’t log in. Because it doesn’t log in, it never triggers an alert. Because it’s not in the HR system, it never appears in access reviews driven by HR data. Because it was created before the current naming convention, it doesn’t get picked up by the automated reports that use that convention.

The leak. The account’s password, set three years ago and never rotated, appears in a credential dump from an unrelated third-party breach — a forum the contractor used with the same password. Attackers run automated credential-stuffing against VPN endpoints and cloud login portals. This one works.

The problem. There’s no MFA on the account because it was classified as a service account during a migration and excluded from the MFA rollout. The exclusion is documented in a spreadsheet from two years ago that nobody has looked at since.

The Zero Trust layer does nothing. The policy engine sees a valid identity. The account is enabled. The password is correct. There’s no MFA requirement. There’s no device compliance requirement because the account isn’t tied to a managed device. The risk score is low because there’s no history of suspicious behavior — the account has been dormant, which the risk engine interprets as “low activity,” not “abandoned.”

Day 1,001 — lateral movement. The account has database rights. The attacker pivots. By the time anyone notices unusual query patterns, they’ve been inside for eleven days and have touched a database containing patient records.

The post-mortem. The security team’s tools worked as designed. The policies were reasonable. The gap was in the identity data those tools and policies depended on. And it wasn’t a technology gap — it was a process gap around the leaver workflow and a governance gap around MFA exceptions.

The fix, once it was done properly. A reconciliation process that compares Active Directory to HR to each application’s user store. A time-limited exception register with mandatory review. A policy that requires MFA on every account with interactive login capability, including accounts historically classified as service accounts. And a named owner for identity hygiene.

Nothing about that fix was exotic. It just required someone to own the problem end to end.

How to Find Your Own Identity Gaps: A Practical Audit

You don’t need a big consulting engagement to find out how bad this is. You need a few queries and a willingness to look.

Here’s a workable starting audit.

Step 1: Get an authoritative list of humans

Pull your current employee and contractor list from HR. Not from IT. HR.

Then pull every human identity from your central directory. Compare the two lists.

• Accounts in the directory with no match in HR → investigate each one.

• People in HR with no directory account → check whether they have accounts in other systems.

Expect noise on both sides. Contractors and vendors won’t be in HR. Some employees won’t have directory accounts. That’s fine. The point is to find the accounts that belong to nobody.

Step 2: Check the last logon date on everything

Run a report of accounts that haven’t authenticated in 90 days, 180 days, and 365 days. Sort by permission level — highest privilege first.

That sorted list is your priority queue. An account with domain admin rights and no logons in a year is the worst kind of finding.

Step 3: Enumerate every identity store

List every system that has its own user database. Include SaaS apps, cloud platforms, on-premises applications, databases, network devices, and CI/CD pipelines.

Most organizations underestimate this by half on their first pass. Ask the application teams. Ask the help desk what they reset passwords on. Ask finance what they pay for.

Step 4: Review every MFA and conditional access exception

Find every exclusion. There will be more than you expect.

For each one, ask three questions: Who approved it? What breaks if we remove it? When was it last reviewed?

Any exception without a clear answer to all three should have a removal date assigned.

Step 5: Inventory non-human identities

Pull every service account, API key, OAuth app, managed identity, and certificate. Get the creation date, the owner, and the permissions.

You will find things. There will be OAuth grants from applications nobody recognizes. There will be service accounts with permissions nobody can explain. There will be secrets older than the last three employees who could have created them.

Step 6: Walk one leaver end to end

Pick an employee who left in the last six months. Trace every system they had access to and verify that access is actually gone.

This is the highest-value test in the whole audit because it tells you whether your leaver process works in practice, not just on paper.

Here’s a simple way to score what you find:

| Finding | Why it matters | Priority |

|—|—|—|

| Enabled account with no HR match and no logon in 180+ days | Classic orphan; easy target | Critical |

| Privileged account without MFA | Single credential defeats everything else | Critical |

| Service account with interactive logon capability | Converts a non-human gap into a human attack path | High |

| Account with access across 5+ systems after a role change | Accumulated privilege; violates least privilege | High |

| MFA exception with no review date | Permanent weakening of a core control | High |

| Unrotated secret older than 12 months in code or config | Leak risk with a long exposure window | High |

| Duplicate accounts for the same person | Confuses policy and review processes | Medium |

| Account with no owner listed | Nobody will ever clean it up | Medium |

Identity Management and Micro-Segmentation Are Two Halves of One Idea

Micro-segmentation gets discussed as a network control, which it is. But it only works if identity is accurate.

Here’s the connection. Micro-segmentation limits what a compromised identity can reach. Identity management limits how many identities can be compromised in the first place, and how far any one of them can go.

If your identity data is clean, micro-segmentation becomes far more effective. You can define segments based on role, and you can trust that the role assignment is current. You can enforce that a developer’s workstation can talk to the development cluster and nothing else, and you can trust that the developer is actually still a developer.

If your identity data is dirty, segmentation gets messy. You end up with broad rules because you can’t confidently define narrow ones. You create exceptions because someone in finance needs access to a system they shouldn’t have, and rather than fix the role, you open a path.

This is the argument for treating identity and segmentation as one program rather than two projects. They share the same dependency: an accurate, current, complete picture of who and what exists in your environment.

Compliance Won’t Save You, But It’s Asking Better Questions Now

Regulated industries spend a lot of energy on compliance, and compliance does force some identity hygiene. But there’s a gap between passing an audit and being secure.

An auditor checks whether you have an access review process. They check whether reviews happened and whether they were documented. They may sample a few accounts. They don’t generally check whether the account list itself is complete, or whether the reviewer had accurate data, or whether a service account created after the review cycle is properly scoped.

So you pass the audit and still have the breach. That’s a common outcome.

That said, the compliance bar is rising. Standards are increasingly requiring things that touch identity directly:

• PCI DSS 4.0 tightened requirements around MFA for all access into the cardholder data environment, including administrative access.

• HIPAA requires access controls and audit controls, which in practice means knowing who accessed what and being able to prove it.

• Sarbanes-Oxley pushes on segregation of duties, which is impossible to demonstrate without accurate role and access data.

Organizations that treat compliance as a continuous process rather than an annual event do better. There’s a reason compliance-as-a-service has become a real category — the regulatory environment changes faster than most internal teams can track, and having someone else watch the horizon helps.

But the fundamental point stands: if your identity data is wrong, compliance is theater. You’re documenting decisions made on bad information.

Common Mistakes When Organizations Try to Close Identity Gaps

I’ve watched a lot of these projects. The failures follow patterns.

1. Treating it as a one-time cleanup. You run the audit, disable 300 accounts, declare victory. Six months later you’re back where you started because nothing about the underlying process changed. Identity hygiene is a rhythm, not a project.

2. Automating a broken process. Robots that create accounts faster still create accounts that nobody cleans up. Fix the process first, then automate it.

3. Disabling accounts without a business review. You’ll disable someone critical’s access on a Friday and find out Monday. Include application owners and business unit leads in the review before you pull the trigger.

4. Ignoring non-human identities because they’re hard. They’re harder to inventory and harder to rotate. They’re also where a lot of modern attacks land. Skipping them means skipping a large part of your exposure.

5. Letting the security team own it alone. Identity hygiene requires HR, IT operations, application owners, and security working from the same data. A security-only effort gets blocked at every step because security doesn’t control the leaver process or the application provisioning.

6. Setting policy without operational buy-in. If the policy says “no standing privileged access” but the on-call engineers can’t get elevated access at 3 a.m., the policy will be bypassed. Break-glass access exists for a reason. Design it deliberately instead of pretending it doesn’t happen.

7. Never measuring anything. If you don’t track the number of orphaned accounts, the percentage of privileged accounts with MFA, the average age of secrets, and the time from termination to full deprovisioning, you have no idea whether things are getting better or worse.

What Good Looks Like: Metrics Worth Tracking

You can’t manage this without numbers. Here are the ones that actually tell you something.

| Metric | What it tells you | Reasonable target |

|—|—|—|

| Orphaned account count | Whether identities are linked to real people | Near zero, reviewed monthly |

| Accounts with no logon in 90+ days | Dormant credential exposure | Under 2% of total |

| % of privileged accounts with phishing-resistant MFA | Core control coverage | 100% |

| Time from termination to full deprovisioning across all systems | Leaver process health | Under 24 hours |

| Number of active MFA/conditional access exceptions | Accumulated policy debt | Trending down, all time-limited |

| Average age of secrets and API keys | Rotation discipline | Under 90 days for high-value secrets |

| % of non-human identities with a named owner | Accountability coverage | Above 95% |

| Access review completion rate with accurate data | Whether reviews mean anything | 100%, with reconciliation first |

None of these require exotic tooling. Most can be pulled from systems you already have. The work is in the reconciliation and in having someone look at the numbers every month.

How Operations and Security Can Actually Work Together on Identity

The underlying issue in almost every case I’ve described is that operations and security run as separate functions with separate priorities, and identity falls into the space between them.

Operations wants systems to stay up. Security wants risk reduced. Both are legitimate. The problem is that decisions get made in isolation — operations changes something without thinking about security impact, security sets policy without thinking about operational feasibility — and identity drift is what accumulates in the gap.

This is the problem Scott Alldridge and the IT Process Institute set out to address with the VisibleOps framework. The core idea is that operational discipline and security discipline aren’t competing priorities. They’re the same discipline applied to different risks. Integrating disciplined change management, continuous incident resolution, and real-time monitoring into a single operating model is how you get identity hygiene to actually stick.

That matters for a practical reason. Identity data doesn’t drift because people are lazy. It drifts because the change process doesn’t ask identity questions, the monitoring doesn’t flag dormant privileged accounts, and the incident process doesn’t feed what it learns back into the configuration baseline. Fix those three things and the drift slows dramatically.

What the VisibleOps approach brings to identity specifically

The VisibleOps Cybersecurity framework — documented across a series of handbooks that have sold over 400,000 copies — approaches identity as part of a broader operating model rather than a standalone security project.

For technical teams, the main VisibleOps Cybersecurity Handbook focuses on integrating the framework with Zero Trust solutions, including the identity and segmentation work that makes Zero Trust enforceable. It covers how change management, incident resolution, and real-time monitoring interact with identity lifecycle management.

For executives who need to understand the business side without the technical detail, the VisibleOps Cybersecurity: Executive Companion Handbook strips out the jargon and acronyms. It’s written for CEOs, COOs, CFOs, board members, and business owners — people who need to make decisions about security investment and risk without needing to know what a service principal is. That matters for identity work specifically, because closing identity gaps requires organizational decisions: who owns identity hygiene, what the leaver process looks like, how much standing privilege the business is willing to tolerate.

There’s also VisibleOps AI: Governance, Risk, and Leadership in the Age of Intelligent Systems, which extends the framework into AI governance. That’s relevant here because AI systems create entirely new categories of non-human identity and access, often with broad permissions and limited oversight.

Scott’s background includes an MBA in Cybersecurity, CCISO and CISSP certifications, Harvard certification in Privacy and Technology, and more than 30 years in IT management and cybersecurity. Beyond the books, he works with organizations directly through training, coaching, and consulting through IP Services, his managed IT and cybersecurity company. If your identity gaps are tangled up with compliance requirements — PCI, HIPAA, Sarbanes-Oxley — there’s also compliance-as-a-service support and penetration testing and vulnerability assessment work that can verify whether your fixes actually hold.

The honest pitch here isn’t that someone else can do identity hygiene for you. It’s that most organizations know they have the problem and can’t get the internal alignment to fix it. An outside framework and an outside voice sometimes break that logjam.

FAQ: Identity Management Gaps and Zero Trust

What’s the difference between an orphaned account and a stale account?

An orphaned account has no identifiable owner — the person left, the role was eliminated, or it was never assigned to anyone. A stale account has an owner but hasn’t been used in a significant period, often 90 days or more. Orphaned accounts are usually the more dangerous of the two because nobody is watching them and nobody will notice unusual activity. Stale accounts are dangerous when they hold privileges or when MFA isn’t enforced on them.

How often should we run an identity reconciliation?

Monthly is a workable baseline for HR-to-directory reconciliation. Anything less frequent and you’re letting drift accumulate faster than you can clean it. For privileged accounts and non-human identities, more frequent review makes sense — quarterly at minimum, monthly if your environment changes quickly.

Our Zero Trust rollout is already underway. Is it too late to fix identity?

No. Identity work can and should run alongside a Zero Trust rollout. In fact, the Zero Trust implementation usually surfaces the identity problems because policies start failing or generating exceptions that trace back to bad data. Treat those exceptions as findings, not as reasons to weaken the policy.

Is it realistic to eliminate all standing privileged access?

For most organizations, fully eliminating standing privilege is a multi-year effort and may never reach 100%. The goal is to minimize it, scope what remains as tightly as possible, enforce strong authentication on it, and monitor it heavily. Break-glass access is a legitimate requirement — it just needs to be designed deliberately, documented, and tested rather than improvised.

How do we handle service accounts that can’t use MFA?

This is a real constraint in some legacy environments. The practical approach is to treat these accounts as high-risk: restrict them to specific source IP addresses, limit their permissions to exactly what the task needs, rotate their credentials on a schedule, and monitor every action they take. Then make it a standing project to eliminate them. Every one you retire is a permanent risk reduction.

What’s the single highest-value thing we could do this quarter?

Pick your highest-privilege accounts — domain admins, cloud admins, database admins — and verify three things for each one: that the owner is a current, identifiable person, that MFA is enforced, and that the account has been used in the last 90 days. You’ll find problems. Fixing them is fast and the risk reduction is immediate.

Does this apply if we’re mostly in the cloud?

It applies more, not less. Cloud environments tend to have more identity stores, more non-human identities, and faster rates of change. The tooling is different but the failure modes are identical.

Getting Started: A 30/60/90 Plan

If you’re convinced you have work to do, here’s a sequence that doesn’t require a huge budget or a six-month planning phase.

First 30 days: see the problem clearly. Run the audit steps above. Get the authoritative HR list, compare it to your directory, pull last-logon data, and enumerate your MFA exceptions. You don’t need to fix anything yet. You need an accurate picture of how bad it is, because that’s what gets executive attention.

Days 31 to 60: fix the highest-risk items. Disable orphaned privileged accounts. Enforce MFA on everything that can take it. Set expiration dates on every exception. Update your leaver checklist to cover every system, not just the directory. Assign a named owner to identity hygiene — one person who is accountable for the whole picture, even if they don’t do all the work.

Days 61 to 90: change the process. Add an identity impact review to your change management process. Add dormant account monitoring to your operational dashboards. Build reconciliation into your monthly rhythm. Start tracking the metrics above and report them up.

After that, it’s maintenance. The organizations that stay clean aren’t the ones that did a heroic cleanup once. They’re the ones that built the cleanup into how they operate.

The Bottom Line

Zero Trust is a good idea. It’s also completely dependent on something most organizations treat as an afterthought.

Your policy engine can only be as strict as your identity data is accurate. Your segmentation can only be as tight as your role assignments are current. Your monitoring can only catch what it can see, and it can’t see an account that nobody knows exists.

The gaps I’ve described here — orphaned accounts, over-privileged service accounts, MFA exceptions, weak leaver processes, unmanaged non-human identities — aren’t exotic. They’re the normal state of most environments. That’s what makes them dangerous. They don’t look like problems. They look like the way things have always been.

Start with the audit. Find your orphaned privileged accounts and your undocumented MFA exceptions. That alone will change how you think about your Zero Trust posture, because you’ll realize how much of it was resting on assumptions.

If you want a structured way to work through it — and a framework that connects identity hygiene to operational discipline instead of treating them as separate projects — the VisibleOps Cybersecurity handbooks are a good place to start. The technical handbook covers the integration with Zero Trust in detail. The Executive Companion Handbook is written for the people who have to sign off on the fix without wading through acronyms. And if you’d rather have help doing the work than reading about it, Scott Alldridge and the team at IP Services work with organizations on exactly this — from identity remediation to compliance alignment to penetration testing that verifies whether the fixes actually hold.

The tools you already bought aren’t the problem. The data underneath them is. Fix that, and everything else starts working the way you expected it to.