Topic starter
24/06/2026 10:04 pm
TL;DR: SSO implementations often still rely on layered signals that answer the wrong question, according to 1Kosmos, while biometric proofing, identity wallets, and verifiable credentials aim to raise assurance across login flows. The bigger issue is that authentication strength must be tied to identity proof, not just more factors, if IAM teams want durable trust.
Editorial analysis by NHI Mgmt Group, based on content published by 1Kosmos: “Inserting Identity into Your SSO Implementation”.
Key questions
Q: Where do SSO implementations fail when teams rely on MFA and risk signals alone?
A: They fail when the programme assumes that enough signals can substitute for verified identity.
Q: Why does stronger identity proofing change the SSO security model?
A: Because it moves the trust decision from inferred confidence to verified identity.
Q: What should IAM teams do with decentralized identity and verifiable credentials?
A: IAM teams should evaluate decentralized identity and verifiable credentials as governance problems first, not as branding changes.
Practitioner guidance
- Define assurance tiers for SSO access Classify applications and transactions by the identity assurance level they require, then align login paths to those tiers instead of applying one universal sign-in policy.
- Introduce identity proofing before first access Require a verified identity record for users who need stronger access, especially where SSO feeds multiple downstream applications or privileged workflows.
- Use wallets for reusable identity presentation Preserve the result of proofing in a wallet so users can present a trusted identity again without repeating full enrolment on every login.
Bottom line: SSO becomes more trustworthy when it verifies identity rather than just collecting extra signals around a login.
Explore further
View Full Forum → | NHI Foundation Course → | Our Services → | Read the full analysis →
25/06/2026 6:52 am
Identity assurance, not factor count, is the real SSO control plane: SSO programmes fail when teams treat authentication as an accumulation of signals instead of a binding to a verified identity. More factors can lower risk, but they do not answer the core governance question of who the subject is. The practitioner implication is that assurance design must start at identity proofing, not at login friction.
A few things that frame the scale:
- Across one million observed logins, 1 in 4 were password-based rather than SSO, 2 in 5 were not protected by MFA and 1 in 5 used a weak, breached or reused password.
A question worth separating out:
Q: What is the difference between authentication strength and identity assurance in SSO?
A: Authentication strength describes how hard it is to complete the login. Identity assurance describes how confidently the organisation knows who completed it. A strong login process can still produce a weak identity decision if the subject was never properly proofed.
👉 Read our full editorial: Identity into SSO: what stronger assurance changes for IAM