Because the authentication method can improve while the governance problem remains unchanged. If an organisation cannot continuously track who or what is enabled, cloud delivery simply masks lifecycle gaps instead of eliminating them.
Why cloud MFA and PKI can improve authentication without fixing identity governance
Cloud MFA and PKI strengthen the sign-in step, but identity risk is often created elsewhere: in provisioning, recovery, exception handling, stale entitlements, and forgotten accounts or certificates. If lifecycle state is not continuously governed, better authentication can give a false sense of control while orphaned access, unused trust paths, and weak offboarding remain live.
That is why programmes can look mature on paper and still fail in practice. The control surface shifts from passwords to tokens, certificates, device trust, and recovery workflows, but the same question still matters: who is enabled, what is still trusted, and what can continue to authenticate after the business thinks it has been removed?
Cloud delivery also makes the gap harder to see because administrators often manage many tenants, directories, and platforms through a central console. The authentication method may be modern, yet identity security programme design is still what determines whether ownership, review, and deprovisioning actually happen at the pace the environment requires.
Where the risk persists: lifecycle, recovery, and trust exceptions
The main failure mode is not weak cryptography, it is incomplete governance around accounts, keys, certificates, and recovery paths. A modern MFA rollout can still leave dormant admins, overprivileged service identities, stale certificates, or broad emergency access untouched, which means compromise or misuse remains possible even when the login flow is phishing-resistant.
PKI creates a similar pattern. Certificate issuance and renewal may be automated, but issuance policy, ownership, revocation, key protection, and environment separation still determine whether the certificate reflects a current, approved trust relationship or a forgotten one that should have been retired.
For cloud operations, that risk becomes more acute when access is distributed across internal staff, contractors, platform integrations, and machine credentials. NHI lifecycle management matters because the control problem is usually discovery and revocation, not just stronger authentication.
What practitioners should measure before they trust the programme
Good programmes are measured by lifecycle evidence, not by the presence of a modern factor. If the team cannot show who owns each identity, when it was last reviewed, when it expires, how recovery is approved, and how quickly revocation propagates, then MFA or PKI is only masking governance gaps.
In practice, the most useful evidence is a current inventory of enabled identities and trust material, plus an exception list that is short, approved, and time-bound. If the inventory cannot distinguish human users, service principals, device trust, and certificates with production reach, the organisation will miss the identities that matter most during an incident.
That is why a machine identity, PKI and certificate lifecycle guide belongs in the operating model alongside IAM governance: the operational risk is not certificate strength alone, but whether expiry, rotation, and revocation are actually under control.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
NIST SP 800-53 Rev 5 provides the primary governance reference for this topic.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST SP 800-53 Rev 5 | IA-5 — Authenticator Management | Cloud MFA and PKI still depend on lifecycle control of authenticators and certificates. |
| IA-9 — Service Identification and Authentication | Cloud environments often rely on service identities and certificate-backed machine auth. | |
| IA-2 — Identification and Authentication (Organizational Users) | MFA only helps when user identity state and account lifecycle are controlled. | |
| Recommendation — Manage authenticator issuance, rotation, and revocation so stale credentials do not remain usable. Authenticate services and workloads with tightly governed non-human credentials and trust paths. Require strong user authentication while keeping joiner-mover-leaver controls current. | ||
Practitioner Guidance
What to prioritise: Start with the identities and trust artifacts that can still authenticate after a role change, tenant change, or employee departure. In cloud environments, that usually means recovery accounts, privileged admins, service identities, and long-lived certificates before ordinary end-user sign-ins.
What to verify: Confirm that deprovisioning, certificate revocation, and exception expiry are observable and enforced. If the programme cannot prove that removal events propagate quickly enough to match the business risk, treat the deployment as incomplete even if the authentication stack is modern.
Common mistake: Teams often equate phishing-resistant MFA or automated PKI with identity security maturity. The better test is whether the organisation can continuously answer who or what is still enabled, who owns it, and what access survives when the original justification has ended.
Practitioner takeaway: Cloud MFA and PKI reduce authentication weakness, but they do not remove identity risk unless lifecycle governance, ownership, and revocation are equally strong.
Related resources from NHI Mgmt Group
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 8, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org