How should state agencies implement Zero Trust when they still rely on legacy identity governance processes?

State agencies should start by aligning identity governance to policy enforcement, not just access administration. That means enforcing role based access control, requiring multi factor authentication, logging privileged activity, and automating provisioning and deprovisioning. A modern IGA layer helps close the gap between policy and execution by keeping permissions current as roles change and by reducing manual error.

Why Legacy Identity Governance Becomes the Bottleneck

Zero Trust changes the question from “who has access?” to “what should be allowed right now, under these conditions?” State agencies often still run identity governance as a periodic administration function, which works poorly when policy enforcement must be continuous. If roles are stale, approvals are manual, and deprovisioning lags, the agency may technically have policies but still fail to enforce them at the point of access.

That gap matters because legacy IGA tends to assume stable jobs, stable entitlements, and predictable review cycles. Zero Trust assumes the opposite: access should be continuously evaluated, minimally scoped, and revocable as context changes. For agencies with long-lived accounts, inherited entitlements, and exception-heavy workflows, the result is usually not a clean migration but a layer of policy that cannot keep pace with the reality of the directory.

For agencies that must keep operating while modernising, the practical problem is sequencing. They do not need to replace every governance process first, but they do need to make governance outputs usable by enforcement systems. In practice, many agencies discover the mismatch only after a privilege review exposes how much access has been carried forward unchanged for years.

How Legacy IGA Fits into a Zero Trust Model

The right approach is to treat identity governance as the source of authoritative intent, then connect that intent to enforcement points that can act in real time. That usually means cleaning up role definitions, tightening joiner-mover-leaver flows, and making sure policy decisions are reflected in access gateways, PAM workflows, MFA requirements, and session controls. NIST’s Zero Trust Architecture guidance is useful here because it frames access as a decision that must be continuously evaluated rather than assumed once an account exists. NIST SP 800-207 Zero Trust Architecture

Legacy IGA can still support Zero Trust if it stops acting like a quarterly attestation machine and starts feeding enforcement with accurate, current attributes. That requires reliable role mapping, timely lifecycle triggers, and clear ownership for exceptions. It also means agencies should distinguish between administrative access approval and runtime authorisation. An approved entitlement is not the same thing as permission to use it everywhere, all the time.

Use IGA to define role intent and entitlement ownership, then enforce access with conditional controls.
Prioritise privileged and high-impact systems first, because those are where stale access becomes most consequential.
Shorten the time between HR, contractor, or case-management events and entitlement updates.
Require step-up verification for sensitive actions even when the account is already known.

Where this fails in practice is in agencies that rely on custom applications, fragmented directories, or exception workflows that bypass enforcement tools because the governance layer can describe policy but cannot operationalise it consistently.

Common Variations and Edge Cases

Tighter access enforcement often increases workflow friction, so agencies have to balance control strength against mission continuity. That tradeoff is especially visible where legacy systems cannot support modern policy engines, or where shared services across departments make role design politically difficult as well as technically messy.

Some environments can move faster by modernising only the controls around high-risk access first. Privileged administration, third-party access, and dormant account cleanup usually produce the clearest early gains. Agencies should also expect that not every legacy role can be made “Zero Trust ready” through policy alone; some entitlements are so broad or ambiguous that they need redesign, not just review.

NIST Cybersecurity Framework 2.0 can help agencies frame governance, protection, and recovery as connected outcomes, but it does not remove the need to translate identity policy into enforceable technical controls. Best practice is evolving, and there is no universal standard for how much legacy IGA can be preserved before the Zero Trust model becomes ineffective.

For agencies that already have governance fatigue, the practical signal of progress is not a perfect role catalogue. It is whether access decisions are becoming more current, more attributable, and less dependent on manual exception handling.

Risk and Threat Considerations

Legacy identity governance creates residual access risk when stale roles, delayed deprovisioning, and manual exception paths leave more privilege in circulation than current policy would allow. In a Zero Trust program, that is not just an administrative defect; it becomes an exposure problem because access can remain valid long after the original business need has ended.

Failure mechanism: The failure chain is usually entitlement drift plus weak enforcement alignment. An account is approved once, inherits access through role changes or legacy groups, and then keeps working because governance reviews do not continuously constrain runtime authorisation. Adversaries and insiders both benefit from that gap, especially when privileged or dormant accounts are left active.

Impact: The agency can end up with unnecessary privilege, slower containment during compromise, and weaker accountability for sensitive actions. In regulated or public-sector environments, that also increases audit findings, complicates incident scoping, and makes it harder to prove that access was actually removed when policy said it should be.

Standards & Framework Alignment

This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.

MITRE ATT&CK address the attack and risk surface, while NIST CSF 2.0, NIST Zero Trust (SP 800-207) and CIS Controls v8 set the governance and control requirements practitioners need to meet.

Framework	Control / Reference	Relevance
NIST CSF 2.0	PR.AA — Identity Management, Authentication, and Access Control	Zero Trust depends on enforcing current identity and access decisions.
Recommendation — Align access decisions to current identity attributes and continuously verify authorization.
NIST Zero Trust (SP 800-207)	ZTA — Zero Trust Architecture	The question is fundamentally about translating trust policy into runtime enforcement.
Recommendation — Implement continuous policy evaluation between identity systems and enforcement points.
CIS Controls v8	6 — Access Control Management	Legacy IGA gaps usually show up as stale privileges and weak account lifecycle control.
	5 — Account Management	Agency identity governance depends on accurate lifecycle handling for accounts and roles.
Recommendation — Remove stale access, tighten provisioning, and revoke inactive accounts promptly. Automate joiner-mover-leaver updates and disable accounts when business need ends.
MITRE ATT&CK	T1098 — Account Manipulation	Over-retained roles and exceptions can be abused to keep unauthorized access alive.
Recommendation — Hunt for abnormal entitlement changes and review accounts with inherited privileges.

Practitioner Guidance

What to prioritise: Start with privileged access, third-party access, and dormant accounts before attempting a full IGA redesign. Those are the areas where stale governance most directly undermines Zero Trust and where enforcement gaps create the highest consequence.

What to verify: Confirm that every governance event that changes risk, such as role change, separation, contractor expiration, or case closure, has a corresponding technical enforcement trigger. If the control only changes a record in the IGA tool, it is not yet a Zero Trust control.

Common mistake: Treating access recertification as proof of continuous control. Recertification can confirm intent at a point in time, but it does not by itself prevent an over-privileged account from remaining active between review cycles.

Practitioner takeaway: The real test is whether identity governance can drive timely enforcement, not whether the agency has a mature approval workflow on paper.