They should extend policy into the existing estate, preserve working authenticators where possible and layer modern methods on top rather than forcing a rip-and-replace. That approach reduces user friction while keeping authentication, audit and compliance controls aligned across old and new systems.
Modernise the policy layer before you modernise the login screen
Public-sector identity modernisation works best when the policy decision point is upgraded ahead of the user experience. The aim is to make old and new authenticators behave consistently under one set of rules, so the organisation can improve assurance without forcing every user into an immediate migration. That means treating legacy directories, devices and federation paths as part of the design, not as exceptions to be removed later.
Preserving working authenticators is often the difference between a controlled transition and a service outage. If a legacy method still meets the risk requirement for a population or workflow, keep it in place while you add stronger methods around it, then phase usage down by policy and telemetry rather than by deadline alone.
Teams modernising government access at scale should also expect mixed-state operations for a long time. The practical question is not whether the estate is fully modern, but whether authentication, logging and access decisions remain coherent while users move between channels, devices and assurance levels.
How to extend modern identity into legacy estates
The safest pattern is usually to introduce a modern control plane that can sit above older systems and broker the right method for each user and application. In practice, that often means centralising policy, adding federation where possible, and using step-up or stronger authenticators only when the transaction or role requires them. This keeps high-risk access under tighter control without breaking everyday access paths.
For legacy users, compatibility is a feature, not a compromise. Teams should map which authenticators are tied to essential workflows, which apps can consume modern assertions, and which endpoints still require a legacy path. That inventory lets you modernise in layers: policy first, then federation, then stronger authentication, and only then retirement of the oldest methods.
Where older systems cannot speak modern protocols directly, wrap them rather than replace them first. A translation or gateway layer can preserve continuity while you reduce direct dependence on brittle credentials or unmanaged local logins. The key is to avoid creating a second, shadow identity system just to keep the old one alive.
What good looks like during a phased transition
A credible transition has three visible qualities: users keep working, controls become stronger in the background, and the organisation can explain exactly which access paths are legacy, modern, or temporary. If you cannot distinguish those states, you do not really have modernisation, you have added complexity.
Good programmes also define exit criteria for legacy methods. That may include low usage, no critical dependency, viable alternatives for all affected groups, and evidence that authentication logs still support audit and incident response. Without those criteria, legacy methods tend to become permanent because no one owns their retirement.
Public-sector environments often need to balance citizen-facing simplicity with workforce assurance and compliance obligations. The practical objective is not uniformity for its own sake, but control consistency, so that step-up, revocation, audit and recovery work across old and new systems with the same operational discipline.
Risk and Threat Considerations
Modernising identity without a transition plan can leave legacy paths as the weakest route into the environment. The main risks are user lockout, duplicated policy logic, and long-lived fallback methods that remain more permissive than the new standard.
Failure mechanism: Teams replace the front end before the control plane, so old authenticators continue operating outside the new assurance model, or they are removed before all dependencies are migrated.
Impact: That can create authentication gaps, inconsistent audit evidence, and an extended attack surface where older credentials or federation paths remain attractive targets.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
NIST SP 800-63, NIST SP 800-53 Rev 5, NIST CSF 2.0 and CIS Controls v8 set the technical controls, while ISO/IEC 27001:2022 defines the regulatory obligations.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST SP 800-63 | Digital Identity Guidelines | Identity assurance and authenticator strength are central to phased modernisation. |
| Recommendation — Align authenticator choices to assurance levels and step up riskier transactions. | ||
| NIST SP 800-53 Rev 5 | IA-2 — Identification and Authentication (Organizational Users) | Workforce identity migration depends on consistent user authentication across legacy and modern paths. |
| IA-5 — Authenticator Management | Preserving and retiring authenticators safely is the core transition issue. | |
| Recommendation — Enforce a unified authentication policy for organizational users across all access paths. Track, rotate and retire authenticators under a controlled lifecycle. | ||
| NIST CSF 2.0 | PR.AA-05 — Identity Management, Authentication and Access Control | The question is about extending identity policy while preserving access continuity. |
| Recommendation — Apply consistent identity and access controls during the migration. | ||
| ISO/IEC 27001:2022 | A.5.16 — Identity management | Modernising without disruption requires governed identity continuity and ownership. |
| Recommendation — Maintain authoritative identity records through the migration. | ||
| CIS Controls v8 | CIS-5 — Account Management | Legacy users and accounts must be governed during phased modernisation. |
| Recommendation — Inventory, validate and retire accounts and authenticators in phases. | ||
Practitioner Guidance
What to prioritise: Start with the identity policy and logging model, then map every legacy dependency that depends on it. If a legacy authenticator still supports a critical service, classify it as a managed transition path, not a technical debt footnote.
What to verify: Confirm that every user group has at least one viable modern path before you deprecate a legacy one, and that revocation, step-up and session traceability work across both generations. The test is whether you can enforce the same access decision consistently, not whether the login experience looks modern.
Practitioner takeaway: In public-sector identity modernisation, continuity is the control objective. Preserve working access long enough to move policy, telemetry and assurance together, then retire legacy methods only after the replacement path is proven in production.
Related resources from NHI Mgmt Group
- How should public sector teams implement mobile digital identity for age checks and service access without forcing users to share full identity documents?
- How can teams reduce Office 365 identity sprawl without disrupting users?
- How should security teams plan a migration away from a legacy identity provider without disrupting access?
- How should security teams layer access governance over legacy identity management without disrupting existing systems?
Deepen Your Knowledge
Free weekly newsletter
Subscribe to the NHI & AI Identity Journal
The latest on NHI and Agentic AI security – articles, research, breaches, news and events every week.
Bonus 33% off our NHI Course when you subscribe.
Reviewed and updated by the NHIMG editorial team on October 11, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org