Notifications
Clear all
Topic starter
08/06/2026 3:59 pm
TL;DR: Cloud authentication maturity has not removed the need for verification, because attackers keep bypassing MFA and exploiting weak cloud trust assumptions, according to Axiad’s blog post and its references to the RSA hack and other incidents. The real shift is from assuming a product is secure to proving the control works across architecture, access, audits, and operational discipline.
NHIMG editorial — based on content published by Axiad: Trust, but verify, 5 tips for selecting a cloud authentication solution
Questions worth separating out
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.
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.
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.
Practitioner guidance
- Verify the full authentication chain Test enrollment, factor verification, recovery, seed storage, admin access, and cloud control paths as one system.
- 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 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.
What's in the full article
Axiad's full blog post covers the operational detail this post intentionally leaves for the source:
- Practical vendor-selection checks for cloud authentication and MFA services
- The five control areas the author recommends evaluating before trusting a provider
- Context on the RSA, OneLogin, and election-related examples referenced in the post
- The original framing for secure development, architecture, access control, and external audits
👉 Read Axiad's blog post on selecting a cloud authentication solution →
Cloud authentication and MFA: are your controls really verified?
Explore further
08/06/2026 5:21 pm
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.
A few things that frame the scale:
- 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.
A question worth separating out:
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.
👉 Read our full editorial: Cloud authentication still fails when teams trust by default
