What breaks when state agencies modernise identity only in the cloud?

Where cloud-only identity modernisation leaves the control plane incomplete

Modernising only the cloud side usually improves governance where the new platform is already authoritative, but it does not automatically extend those controls to everything that still depends on legacy authentication, local policy stores, or separate recovery paths. The result is not just dual administration, but a split trust model: one set of rules in the cloud, another in older systems that continue to issue access or fall back when the cloud path is unavailable.

That split matters because identity control is only as strong as the weakest place where access is still decided. If a legacy app, a network access service, or an emergency help desk process can still grant, reset, or preserve access outside the cloud control plane, then the organisation has not actually centralised identity. It has only centralised part of it.

Cloud migration also tends to hide the dependency stack. A state agency may believe it has a modern zero trust posture because Microsoft Entra ID, conditional access, and cloud audit are well governed, yet the real access decision can still be made by a identity security programme that never fully mapped legacy dependencies, ownership, and recovery paths. That is where policy drift starts: the control that looks modern is not the control that actually grants access.

Which dependencies keep working outside the cloud?

Three classes of dependency commonly survive cloud modernisation. First are legacy applications that still authenticate against on-premises directories, Kerberos, RADIUS, or locally stored service credentials. Second are operational recovery paths, especially help desk password resets, break-glass access, and manual exception handling. Third are high-assurance or segregated environments, where policy is intentionally different and often slower to modernise because of regulatory, technical, or operational constraints.

Each of these can become a separate authority for access. The important point is not that they are old, but that they create different assurance levels and different enforcement points. When one environment uses modern policy and another uses inherited controls, users, administrators, and machines do not experience one consistent identity system. They experience a patchwork of exceptions.

The practical issue is visibility. Agencies often know they have these dependencies, but not how many of them still bypass the cloud plane, who owns them, or whether they are still used in production. A lifecycle view helps here: lifecycle management is what turns hidden dependencies into inventoried, reviewed, and eventually retired access paths.

Cloud-to-legacy gaps are especially persistent when the organisation has not rationalised service credentials, shared break-glass accounts, and segregated operational environments. Those are not edge cases, they are often the exact places where continuity planning and identity governance collide.

Why weak points remain attractive even in a well-governed Microsoft estate

A well-governed cloud tenant can still be undermined by the systems around it. Attackers do not need to break the strongest control if they can use a weaker adjacent one. In practice that means they target password reset workflows, legacy protocol paths, stale privileges, and old service accounts because those routes often have broader reach than the cloud policy surface.

That is why identity modernisation has to include the full access path, not only the primary sign-in experience. When agencies leave legacy authentication or recovery outside the main control plane, they create parallel entry points that may not inherit the same MFA strength, monitoring, or revocation discipline. Workload and service identities are particularly important here because they often bridge cloud and legacy systems, and the bridge is only as safe as the weakest credential or trust relationship on either side.

Cloud-only modernisation also raises the odds of false confidence. Teams may assume the strongest control is the one that matters most, when in reality the most dangerous path is the one least visible to the central team. That is why exception paths deserve the same scrutiny as the primary cloud policy path, especially where they can reset, preserve, or extend privileged access.

Cloud workload identity patterns help close one common gap, but they do not solve legacy application dependencies by themselves. The agency still needs to decide which remaining systems must be modernised, which should be isolated, and which should be retired rather than wrapped in a permanent exception.

Risk and Threat Considerations

Cloud-only modernisation creates a split-control environment that attackers can exploit through the weaker path. Legacy authentication, help desk resets, and recovery accounts often have broader reach than their owners realise, so one bypass can undo the assurance gained in the cloud.

Failure mechanism: A non-cloud dependency remains authoritative for authentication or recovery, so policy, logging, and revocation do not apply consistently across the full access path.

Impact: Attackers or insiders can use the weakest legacy route to regain access, preserve persistence, or bypass stronger cloud controls even when the main Microsoft environment is well governed.

Practitioner Guidance

What to measure: Track the count of production systems still dependent on legacy auth, the number of manual exception paths, and the share of privileged recovery actions that occur outside the cloud control plane. If those figures do not trend down, modernisation is incomplete.

Escalation / exception: Escalate any legacy path that can issue, reset, or extend privileged access without the same approval, logging, and revocation controls used in the cloud. Those paths should be time-bound exceptions, not permanent architecture.

Practitioner takeaway: Zero trust fails first at the boundary you forgot to classify, own, or retire.

Practitioner Guidance

What to prioritise: Map every access path that can still authenticate, reset, or recover access outside the cloud control plane. If you cannot name the owner, protocol, and fallback condition for a legacy path, treat it as an unmanaged control surface rather than a tolerated exception.

What to verify: Check whether legacy applications, RADIUS flows, help desk processes, and high-assurance environments inherit the same policy outcomes as the cloud tenant, or whether they silently override them. The test is simple: can a user or service regain access without the cloud control plane knowing?

Common mistake: Treating cloud governance as proof of end-to-end identity governance. Modern cloud controls are necessary, but they are not complete until the agency has either brought the legacy path under the same policy regime or deliberately fenced it off with compensating controls.

Practitioner takeaway: The real question is not whether the cloud identity stack is modern, but whether any other path can still decide access after the cloud stack says no.

Related resources from NHI Mgmt Group

• What breaks when state agencies treat identity management as separate from cybersecurity priorities?
• How should security teams prioritise NHI remediation in cloud environments?
• How should security teams govern non-human identities in cloud environments?
• When does a machine identity become a compliance problem?