Notifications
Clear all
Topic starter
12/06/2026 10:04 pm
TL;DR: Cloud authentication remains vulnerable when teams assume products are secure instead of verifying architecture, software development, access controls, and third-party assurance, according to Axiad. The governance lesson is unchanged: cloud authentication must be evaluated as a control surface, not a trust claim.
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: They should evaluate the provider as a control system, not a brand.
Q: Why do cloud authentication systems create concentrated risk?
A: Because a single service can sit in the access path for many users, systems, and tenants at once.
Q: What do organisations get wrong when choosing cloud authentication?
A: They often confuse adoption with assurance.
Practitioner guidance
- Require evidence for control design Ask for architecture diagrams, secure development practices, vulnerability management evidence, and privileged access controls before approving a cloud authentication service.
- Validate tenant isolation claims Confirm that compromise of one customer environment cannot expose shared authentication assets or administrative pathways affecting other tenants.
- Make external audit proof mandatory Treat third-party certification as a procurement gate, and verify the scope, recency, and independence of the audit before renewal.
What's in the full article
Axiad's full blog post covers the operational detail this post intentionally leaves for the source:
- The specific questions the author recommends asking before selecting a cloud authentication solution.
- The article's full discussion of secure software development and deployment practices.
- The full explanation of architecture compartmentalisation and why it limits tenant blast radius.
- The author's rationale for treating third-party compliance audits as a trust check, not a formality.
👉 Read Axiad's cloud authentication guidance on verifying trust, not assuming it →
Cloud authentication trust gaps: are your controls really verified?
Explore further
13/06/2026 12:36 am
Trust is the wrong control model for cloud authentication. Cloud authentication systems are often adopted as if maturity and market presence were proof of security, but the article shows that verification must replace assumption. Identity controls only work when the architecture, deployment pipeline, and administrative boundaries are independently validated. Practitioners should treat every cloud authentication product as a control surface that must earn trust continuously.
A few things that frame the scale:
- 80% of identity breaches involved compromised non-human identities such as service accounts and API keys, 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 what is actually trusted, according to the Ultimate Guide to NHIs.
A question worth separating out:
Q: Who is accountable if a cloud authentication service is compromised?
A: The provider is accountable for operating the service securely, but the customer remains accountable for due diligence, procurement review, and dependency governance. Identity teams should demand external assurance and document how they would respond if the service's trust assumptions fail.
👉 Read our full editorial: Cloud authentication still fails when trust is assumed over verified
