Why cloud MFA and PKI programmes still create identity risk

At a glance

What this is: Axiad says cloud identity deployments still require constant attention because users, machines, and applications must be inventoried, enabled, and governed across an evolving environment.

Why it matters: This matters because IAM teams can reduce rollout friction without reducing identity risk, especially where non-human identities and application enablement expand faster than governance.

By the numbers:

• 80% of identity breaches involved compromised non-human identities such as service accounts and API keys.
• Only 5.7% of organisations have full visibility into their service accounts.
• 97% of NHIs carry excessive privileges, increasing unauthorised access and broadening the attack surface.

👉 Read Axiad's blog on reducing cybersecurity risk in cloud identity deployments

Context

Cloud identity programmes often fail not because the authentication technology is weak, but because the surrounding governance never catches up. Once MFA, PKI, and related controls are delivered as services, the harder problem becomes keeping track of users, machines, and applications as they change, multiply, and interact.

For IAM and NHI teams, the issue is lifecycle discipline: inventory, enablement, verification, and offboarding all have to keep pace with a constantly changing estate. A cloud deployment can shorten implementation time, but it does not eliminate the need for visibility, policy, and accountability across every digital identity in scope.

Key questions

Q: How should security teams govern identity when authentication moves to the cloud?

A: They should treat cloud authentication as part of a broader lifecycle control model. That means maintaining an authoritative inventory, separating human and non-human identity flows, and tracking exceptions during migration. If the programme only measures deployment speed, it will miss stale accounts, shadow access, and legacy paths that continue to carry risk.

Q: Why do cloud MFA and PKI programmes still need strong IAM processes?

A: Because the control problem moves from infrastructure to governance. Cloud delivery can simplify implementation, but it does not remove the need to know who and what is in scope, how identities are verified, and when access should be revoked. Without those processes, the environment becomes easier to deploy but harder to trust.

Q: What breaks when application enablement is not managed carefully?

A: Teams usually create parallel access paths, manual exceptions, and legacy authentication routes that outlive the migration. Those gaps make it difficult to prove who is actually using a system and whether the intended control is in place. The result is a programme that looks modern while still carrying old risk.

Q: How do organisations know whether cloud identity rollout is actually improving security?

A: Look for fewer unsupported exceptions, cleaner identity inventories, and a measurable reduction in legacy authentication dependencies. If adoption is rising but exceptions are also rising, the programme has probably moved faster than governance. Security improves when the control state becomes clearer, not just when the platform goes live.

Technical breakdown

Why cloud MFA does not remove identity governance work

Cloud delivery changes the operating model, not the governance requirement. MFA and PKI still depend on accurate identity inventory, reliable enrolment, and ongoing assurance that the right subject is bound to the right credential. The weak point is usually not authentication itself, but the control surface around it: who is entitled, who is enabled, which systems are still using legacy paths, and which accounts were never fully retired. In other words, the platform may be simpler to run, but the identity estate is not simpler to govern.

Practical implication: treat cloud IAM as a governance programme with a delivery model, not as a finished control.

Application and system enablement is the real scaling problem

The article’s core technical point is that inventorying and verifying digital identities becomes harder as more systems, devices, and applications are added. Each integration creates another trust relationship, another authentication path, and another place where identity state can drift from policy. That is especially true when human and non-human identities coexist in the same environment, because the same platform must distinguish interactive users from workloads, service accounts, and automated systems. Without that separation, teams lose clarity on what is being authenticated and why.

Practical implication: build an authoritative inventory for both human and non-human identities before expanding cloud enablement.

Why enablement services matter after deployment

Implementation is only the first phase. The article emphasises that user enablement, communication, and phased rollout matter because identity changes create friction even when they improve security. Technically, that means authentication policy has to be paired with adoption management, migration paths, and exception handling for legacy applications that cannot move at the same pace. If those transitions are not governed, teams end up with shadow exceptions, parallel authentication routes, and lingering legacy access that undermine the intended security model.

Practical implication: plan migration and exception handling as part of the control design, not as post-launch cleanup.

NHI Mgmt Group analysis

Cloud identity delivery shifts the bottleneck from implementation speed to governance depth. Axiad’s argument is that faster deployment does not equal lower risk, because the estate still has to be inventoried, verified, and maintained. That is the real identity security test for cloud MFA and PKI programmes. Practitioners should judge these projects by whether they improve control over the full lifecycle, not by how quickly they go live.

Application enablement is where identity programmes usually fail at scale. The article correctly focuses on the growing number of devices, systems, and applications that must be tied back to known identities. That pattern is familiar across IAM and NHI programmes: once the environment becomes heterogeneous, unmanaged exceptions become the default failure mode. The practitioner takeaway is to treat application onboarding and identity verification as a single governance problem.

Identity inventory debt: the programme risk created when teams cannot say which users, machines, and applications are still active, which are legacy, and which are safe to retire. That debt accumulates when cloud adoption outpaces lifecycle management, and it is often the real reason identity controls look stronger on paper than in practice. The implication is that governance teams need a living inventory before they can claim control.

Cloud-based authentication only reduces risk when lifecycle processes stay synchronized with platform change. The article shows that enablement, communication, and phased rollout are part of the security model, not separate change-management chores. Where those processes are weak, organisations create parallel paths, stale access, and unmanaged dependencies. The practitioner conclusion is that lifecycle governance has to be designed into every identity deployment.

From our research:

• Only 5.7% of organisations have full visibility into their service accounts, according to the Ultimate Guide to NHIs.
• 91.6% of secrets remain valid five days after the targeted organisation is notified, showing a critical gap in remediation procedures.
• For a broader baseline, 52 NHI Breaches Analysis shows how identity failures become operational incidents when visibility and revocation lag behind change.

What this signals

Identity inventory is the next constraint for cloud-first IAM programmes. Faster deployment of MFA or PKI will not compensate for weak visibility across users, applications, and machine identities. When only 5.7% of organisations have full visibility into their service accounts, the governance problem is not adoption. It is control.

Identity blast radius: the hidden risk created when cloud enablement scales before the organisation knows which identities, systems, and exceptions still matter. That is why rollout metrics need to be matched with lifecycle metrics, especially for workload and service-account governance.

Practitioners should expect cloud identity programmes to converge with NHI lifecycle management and Zero Trust controls. NIST Cybersecurity Framework 2.0 is useful here because the issue is not only protection, but continuous identification, detection, and recovery across changing identity state.

For practitioners

• Inventory every identity before expanding enablement Build a current register of users, machines, applications, and service accounts so you can see what is actually being authenticated and where legacy paths still exist.
• Separate human and non-human onboarding paths Use distinct enrolment, verification, and exception workflows for interactive users and workload identities so one control model does not blur into another.
• Treat migration friction as a control signal Track failed enrolments, fallback authentication, and manual exceptions during rollout because they reveal where policy, communication, or application readiness is weak.
• Tie offboarding to system retirement Revoke access and retire credentials when applications or services are decommissioned so cloud enablement does not leave unused identities behind.

Key takeaways

• Cloud MFA and PKI can simplify deployment without simplifying identity risk, because governance still has to track every user, machine, and application in scope.
• Visibility into service accounts remains poor across most organisations, which means identity programmes often operate with blind spots that cloud delivery does not remove.
• The practical fix is lifecycle discipline: inventory, onboarding, exception handling, and offboarding must move in step with every identity change.

Key terms

• Identity Inventory: A current record of the identities an organisation relies on, including users, systems, applications, and service accounts. In practice, inventory is the foundation for governance because you cannot review, verify, or retire access if you cannot reliably say what exists.
• Application Enablement: The work of connecting applications and systems to a modern identity control model without breaking business use. It includes migration planning, authentication mapping, exception handling, and verification that old paths are not left running after the new model is in place.
• Lifecycle Governance: The discipline of managing identity from introduction through change and retirement. For cloud identity programmes, it means enrolment, policy enforcement, monitoring, recertification, and revocation stay aligned as users, machines, and applications evolve.
• Digital Identity: Any identity used by a person, device, application, or automated process to gain access to systems. The term covers both interactive and non-human subjects, which is why governance has to account for credential issuance, usage, and removal across multiple identity types.

Deepen your knowledge

NHI governance, agentic AI identity, and machine identity security are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are responsible for identity security strategy or NHI governance in your organisation, it is worth exploring.

This post draws on content published by Axiad: Are You Doing Everything You Can to Mitigate Your Cyber Security Risks? Read the original.