Cloud authentication still fails when teams trust by default

At a glance

What this is: Axiad’s post argues that cloud authentication cannot be trusted by default and that security teams must verify architecture, controls, and third-party assurance before assuming MFA is effective.

Why it matters: It matters because identity teams must treat cloud authentication, MFA, and provider assurance as governance problems, not marketing claims, across human, NHI, and autonomous environments.

👉 Read Axiad's blog post on selecting a cloud authentication solution

Context

Cloud authentication is not secure simply because it is widely adopted. In practice, MFA, cloud isolation, infrastructure access control, and third-party assurance all have to be validated together, because attackers repeatedly look for the weakest link in identity-dependent systems.

The identity governance issue is broader than one control family. When a provider handles authentication or stores identity material, IAM and security teams need proof of secure development, compartmentalised architecture, audited access, and external validation before they treat the service as trustworthy.

Key questions

Q: How should security teams evaluate a cloud authentication provider?

A: Security teams should evaluate cloud authentication providers by testing the full control chain, not just the login experience. That means reviewing architecture, tenant isolation, secure development practices, privileged access, logging, and third-party assurance before trusting the service with identity enforcement.

Q: Why can MFA still fail in cloud environments?

A: MFA can fail when attackers bypass the factor by targeting the surrounding identity system, such as recovery processes, seed storage, administrative access, or provider infrastructure. The weakness is often in the trust model around MFA, not the factor itself.

Q: What should organisations ask before adopting a cloud identity service?

A: Organisations should ask how the vendor compartmentalises tenants, how it protects secrets and seeds, what internal access exists to the infrastructure, and which independent audits or tests validate those controls. Those questions turn trust into evidence.

Q: How do teams know if a cloud authentication control is actually trustworthy?

A: A trustworthy control produces evidence. Teams should look for secure software development, compartmentalised architecture, documented access controls, and external assurance that can be reviewed and repeated, rather than relying on claims that the service is mature or widely used.

Technical breakdown

MFA bypass and trust failure in cloud authentication

Multi-factor authentication reduces account takeover risk, but it does not eliminate design, implementation, or operational weaknesses around the service that enforces it. Attackers often target the surrounding identity system rather than the factor itself, including authentication infrastructure, seed storage, recovery paths, and cloud control planes. The post’s examples show that even mature MFA programmes can fail when the underlying trust model is assumed rather than tested. In cloud environments, the issue is not just whether a second factor exists, but whether the full authentication chain resists compromise under real attack conditions.

Practical implication: validate the complete authentication path, not only the MFA prompt.

Cloud architecture, segmentation, and tenant isolation

A cloud authentication service must be compartmentalised so a compromise in one area does not become a platform-wide breach. That requires secure architecture, strong tenant separation, and controlled internal access to infrastructure and privileged management layers. The article’s point is that identity security depends on how the cloud service is built and isolated, not on the presence of a login control alone. For IAM teams, architecture is part of the trust decision because shared infrastructure can turn a single failure into many customer impacts.

Practical implication: assess tenant isolation and internal access paths before approving cloud identity services.

Third-party audits and secure development as identity evidence

Third-party certification, vulnerability scanning, code review, and penetration testing are evidence that a cloud authentication provider is operating an information security programme, not just making claims. These controls do not guarantee immunity, but they provide the verification layer that the blog argues is missing from blind trust. For identity governance, this is especially relevant when the service stores secrets, seeds, or privileged configuration data. Security teams should treat assurance artefacts as part of the control set, not as optional paperwork.

Practical implication: require auditable evidence of secure development and external assurance before procurement.

Breaches seen in the wild

• LiteLLM PyPI package breach — LiteLLM PyPI supply chain attack, credentials stolen from users.
• Shai Hulud npm malware campaign — Shai Hulud campaign: npm malware exposed secrets on GitHub.

Read our 52 NHI Breaches Analysis report for a comprehensive view of breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

Trust-based authentication is an assumption, not a control. The blog’s central message is that security teams cannot infer safety from maturity, market adoption, or brand recognition. Authentication systems fail when teams treat trust as a default state instead of something that must be continually verified. The practitioner conclusion is that identity assurance has to be evidence-led, not reputation-led.

Cloud authentication is only as strong as its weakest internal dependency. The article’s examples point to a recurring governance problem: attackers do not need to defeat MFA directly if they can compromise the seed vault, the infrastructure, or the service provider’s access paths. That makes architecture, segregation, and operational access part of the identity control surface. The practitioner conclusion is that provider trust must be assessed end to end, not by feature checklists.

Third-party assurance is part of identity governance, not a procurement formality. The post correctly pushes teams to ask for secure development evidence and external audits because identity services are high-value targets. In NHI and human IAM alike, the service that authenticates users or workloads becomes a control dependency that needs proof, not assumption. The practitioner conclusion is to require verifiable assurance before the control becomes production-critical.

Identity attack surface grows when organisations outsource verification but keep ownership of the risk. Cloud authentication can concentrate risk if the provider’s internal controls, customer isolation, or privileged administration are weak. That creates a governance gap where the buyer depends on a supplier’s control environment without enough visibility into it. The practitioner conclusion is that identity risk management must extend into supplier assurance and shared-responsibility review.

From our research:

• 97% of NHIs carry excessive privileges, increasing unauthorised access and broadening the attack surface, according to Ultimate Guide to NHIs.
• Only 5.7% of organisations have full visibility into their service accounts, which means most identity programmes cannot prove where privilege actually sits.
• That visibility gap is why teams should pair access review discipline with 52 NHI Breaches Analysis when they want to understand how weak governance turns into real incidents.

What this signals

Cloud authentication governance is converging with NHI risk management. As more authentication, secrets, and service access are externalised into cloud services, the buyer inherits a control dependency that must be governed like any other NHI-critical asset. The question is no longer whether a provider uses MFA, but whether the service can be independently verified across architecture, access, and assurance.

Trust, but verify is becoming an identity operating model, not a slogan. Teams that treat cloud authentication as a procurement checkbox will miss the real risk: hidden administrative access, weak tenant separation, and unmanaged provider dependencies. For organisations trying to build resilient IAM, the next step is to connect supplier assurance with runtime identity controls and audit evidence.

Identity attack surface is now a supply-chain issue. When the control that authenticates users or workloads sits outside the organisation, security teams need to know who can administer it, how it is isolated, and what happens when the provider fails. That is where cloud IAM, NHI governance, and third-party risk management overlap.

For practitioners

• Verify the full authentication chain Test enrollment, factor verification, recovery, seed storage, admin access, and cloud control paths as one system. Do not approve MFA based on feature presence alone. The control must be resilient across the entire authentication flow.
• Review cloud tenant isolation assumptions Ask how the service compartmentalises customer data, privileged administration, and internal tooling so one compromise does not become a shared breach. Require architecture evidence, not just a security statement.
• Require external assurance artefacts Collect third-party audit reports, penetration test summaries, and secure development evidence before trusting a cloud authentication provider with critical identity functions.
• Map provider access to identity risk Document who inside the provider can touch secrets, infrastructure, and authentication logic, then review that access as part of supplier governance and privileged access oversight.

Key takeaways

• The post argues that authentication security cannot be assumed just because a solution is widely adopted or marketed as mature.
• The core risk is not MFA alone but the larger trust chain around cloud authentication, including architecture, seeds, privileged access, and audits.
• Practitioners should verify provider controls with evidence before making cloud authentication a dependency of their identity programme.

Key terms

• Cloud Authentication Trust Model: The set of assumptions an organisation makes about how a cloud identity service proves, protects, and enforces authentication. In practice, this includes architecture, recovery paths, privileged administration, and assurance evidence, all of which can fail even when the login flow looks sound.
• Tenant Isolation: The separation that prevents one customer’s compromise from spreading into another customer’s environment in a shared cloud service. It depends on compartmentalised architecture, access boundaries, and administration controls, not just logical separation claims from the provider.
• Identity Assurance Evidence: The auditable proof that an identity control is operating as claimed. This can include secure development practices, third-party audits, vulnerability testing, and access governance records. It matters because identity buyers need verifiable control behaviour, not assertions of maturity.

Deepen your knowledge

Cloud authentication governance, verification discipline, and identity assurance are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are building a programme around provider trust and identity control evidence, it is worth exploring.

This post draws on content published by Axiad: Trust, but verify, 5 tips for selecting a cloud authentication solution. Read the original.