TL;DR: Customer identity fraud remains costly, with Javelin Strategy & Research cited by Strivacity showing new account fraud rose 109% and account takeover losses rose 90% in 2021, while the average victim loss exceeded $1,000. The practical lesson is that CIAM trust now depends on verifiable controls across authentication, security, and accessibility, not brand claims.
At a glance
What this is: This is a Strivacity blog post arguing that CIAM credibility now rests on externally validated security, accessibility, and authentication standards, with fraud trends showing why customer identity controls matter.
Why it matters: It matters because the same trust, access, and lifecycle decisions that shape customer IAM also inform NHI and autonomous identity programmes, especially where phishing resistance, accessibility, and assurance are all part of the control surface.
By the numbers:
- In 2021 new account fraud rose 109% and account takeover losses increased 90% year over year.
- The average per-victim loss across all types of identity fraud was more than $1,000.
- Credit card use more than tripled from 15.6B transactions in 2000 to 51.1B in 2021.
👉 Read Strivacity's post on CIAM certifications, passkeys, and accessibility
Context
Customer identity and access management is the control layer that stands between a public sign-up or sign-in flow and account fraud, data exposure, or poor user experience. In this post, the primary issue is not feature selection but whether CIAM can be trusted to protect customers while remaining accessible across devices and channels.
Strivacity uses its own certifications and standards posture to make a broader point: online brands need externally verifiable controls, not just claims about resilience or usability. That framing matters for IAM teams because the same assurance logic increasingly shows up across customer identity, service identities, and agentic access patterns.
The post is typical of a vendor-authored trust and standards explainer, but the underlying governance question is durable: what evidence proves an identity system is secure enough for real users, real transactions, and real accessibility constraints?
Key questions
Q: How should security teams evaluate CIAM providers beyond marketing claims?
A: Security teams should ask for independent evidence of control design, audit scope, and operating effectiveness, then test whether those controls actually cover login, recovery, and maintenance journeys. Certifications can support the decision, but they should not replace a detailed review of access assurance, privacy handling, and exception paths.
Q: When does passwordless authentication create new governance risk?
A: Passwordless becomes risky when organisations focus only on the happy path and ignore enrolment, device binding, fallback recovery, and support-mediated reset flows. Those paths are where attackers often pivot, and they are also where legitimate users are most likely to be forced into weaker workarounds if controls are not well designed.
Q: Why does accessibility matter in identity and access management?
A: Accessibility matters because identity control is only effective if legitimate users can complete authentication and account maintenance without bypassing security or relying on unsafe manual help. Poor accessibility creates friction, exceptions, and support dependencies that weaken the overall access model and increase operational risk.
Q: Should customer identity teams use fraud trends to prioritise controls?
A: Yes. Rising new account fraud and account takeover losses are direct signals that identity journeys need stronger assurance, especially around registration, authentication, and recovery. Teams should use fraud data to decide where to invest in phishing-resistant authentication, stronger recovery controls, and usability testing that reduces unsafe workarounds.
Technical breakdown
CIAM assurance and third-party certifications
Customer IAM depends on proving that sign-up, sign-in, and account maintenance flows are controlled enough to resist fraud and preserve trust. Certifications such as SOC 2 and PCI DSS do not replace architecture, but they do provide external evidence that policies, controls, and auditability exist beyond vendor self-attestation. For CIAM, the governance value is assurance at the service boundary: can the provider show that controls are tested, not just documented? That matters because customer identity failures usually emerge at the interface between policy, user experience, and operational control. Practical implication: treat certifications as evidence to validate, not as a substitute for your own access, privacy, and resilience review.
Practical implication: map customer identity assurance requirements to independently reviewed controls before approving a CIAM provider.
Passkeys, FIDO2, and phishing-resistant authentication
FIDO2 and passkeys reduce dependence on passwords by shifting authentication to device-bound, phishing-resistant credentials. In CIAM, that matters because customer users bring inconsistent devices, different recovery needs, and varying tolerance for friction. The technical change is not only better login security, but also a different failure model: password reuse and credential phishing become less central, while enrolment, device binding, and account recovery become the new control points. If those recovery flows are weak, the security gain is incomplete. Practical implication: evaluate passwordless design together with recovery, fallback, and support processes rather than treating passkeys as a standalone fix.
Practical implication: test device binding and recovery paths before scaling passwordless authentication.
WCAG and accessible access management
Accessibility is part of identity control, not a separate design concern. WCAG asks whether login and account flows are perceivable, operable, understandable, and robust for people with disabilities. In CIAM, that includes labels, error handling, focus order, timeouts, and alternate paths that do not weaken security. The governance challenge is balancing strong authentication with usability for customers who rely on assistive technologies. That is why accessibility and security need to be evaluated together: a secure login that blocks legitimate users is still a failed control. Practical implication: review authentication and recovery journeys for accessibility defects during security testing, not after release.
Practical implication: include accessibility checks in security QA for every authentication and recovery flow.
Breaches seen in the wild
- Cisco DevHub NHI breach — IntelBroker exploited exposed Cisco credentials, API tokens and keys in DevHub.
- Sisense breach — unauthorized GitLab access led to exfiltration of access tokens, API keys and certificates.
Read our 52 NHI Breaches Analysis report for a comprehensive view of breaches impacting Non-Human Identities including AI Agents.
NHI Mgmt Group analysis
CIAM trust is now an evidence problem, not a branding problem. External certifications matter because customer identity systems sit at the boundary between fraud, privacy, and usability. When a provider points to SOC 2, PCI DSS, FIDO2, and WCAG together, the useful signal is that trust must be demonstrated across distinct control domains, not asserted as a platform virtue. Practitioners should treat assurance as a validation exercise across evidence, not a marketing checklist.
Phishing-resistant authentication only works when recovery is equally governed. FIDO2 and passkeys reduce one class of identity fraud, but they shift risk into enrolment, device binding, and fallback recovery. That means the real governance question is whether the control set around passwordless access is as strong as the login itself. Practitioners should avoid treating authentication modernisation as complete until recovery paths are also verified.
Accessibility is part of access control, not an afterthought. WCAG shows that identity journeys must be usable for the full population of legitimate customers, including those using assistive technology. A login that is secure but functionally inaccessible is not an acceptable control outcome because it pushes users into weaker workarounds or support-mediated exceptions. Practitioners should review accessibility and security together as one identity assurance surface.
Customer identity governance is converging with broader identity assurance discipline. The same expectations that shape CIAM, external auditability, and secure recovery are now visible in NHI and agentic programmes: proof, lifecycle, and user-safe control paths matter more than isolated technical features. The field is moving toward evidence-based identity governance across human and non-human populations, and practitioners should design their programmes accordingly.
From our research:
- Only 19.6% of security professionals express strong confidence in their organisation's ability to securely manage non-human workload identities, according to The 2024 Non-Human Identity Security Report.
- Another 35.6% of organisations cite managing consistent access across hybrid and multi-cloud environments as their top NHI security challenge, which shows that lifecycle complexity is still outrunning governance.
- For a broader view of lifecycle control, see NHI Lifecycle Management Guide and compare it with Ultimate Guide to NHIs , Lifecycle Processes for Managing NHIs.
What this signals
Customer identity programmes are under pressure to prove assurance in ways that map cleanly to fraud outcomes, accessibility obligations, and audit evidence. As passwordless and standards-based authentication mature, the next governance question is not whether the login is modern, but whether the full identity journey remains defensible under operational scrutiny.
Assurance debt: when teams adopt stronger login standards without equally strong recovery, accessibility, and evidence capture, they accumulate hidden control debt that only appears during fraud events or audits. The practical response is to treat identity journeys as an end-to-end control surface and validate them with both internal testing and external standards references such as NIST Cybersecurity Framework 2.0 and NIST SP 800-63 Digital Identity Guidelines.
For practitioners
- Validate external assurance claims Require evidence for certifications, audit scope, and control coverage before accepting a CIAM provider into a customer-facing trust path.
- Test passwordless recovery end to end Review enrolment, device binding, fallback authentication, and support-assisted recovery together so passkeys do not create a new weak link.
- Bake accessibility into security testing Include WCAG checks for labels, error states, focus order, and timeout behaviour in every login and account-maintenance release.
- Tie fraud metrics to identity control decisions Use account takeover, new account fraud, and support exception data to decide whether authentication and recovery controls need redesign.
Key takeaways
- CIAM trust depends on verifiable controls, not vendor assurances alone.
- Passwordless authentication reduces phishing exposure only when recovery and fallback paths are equally governed.
- Accessibility is part of secure access design because unusable login flows create exceptions that weaken identity control.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Non-Human Identity Top 10 address the attack and risk surface, while NIST SP 800-63 and NIST CSF 2.0 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST SP 800-63 | FIDO2 and passwordless login align with digital identity assurance and authentication strength. | |
| NIST CSF 2.0 | PR.AC-1 | CIAM controls govern who can authenticate and under what conditions. |
| OWASP Non-Human Identity Top 10 | NHI-08 | The report's NHI confidence gap connects to workload identity governance and assurance. |
Use NHI-08 to assess whether identity assurance evidence matches operational reality across non-human accounts.
Key terms
- Customer Identity and Access Management: Customer Identity and Access Management is the control layer that handles sign-up, sign-in, profile access, and account maintenance for external users. It must balance fraud resistance, privacy, usability, and accessibility while supporting the business systems that rely on trustworthy customer authentication.
- Passkey: A passkey is a phishing-resistant authenticator that replaces passwords with device-bound cryptographic credentials. In practice, it reduces credential reuse and password theft, but the surrounding enrolment, recovery, and device-binding process still determines whether the overall identity flow is secure.
- Web Content Accessibility Guidelines: Web Content Accessibility Guidelines are technical standards for making web and app interfaces usable by people with disabilities. In identity systems, they shape whether login and recovery flows are perceivable, operable, understandable, and robust enough to support secure access without forcing unsafe workarounds.
Deepen your knowledge
CIAM assurance, phishing-resistant authentication, and accessible access design are all core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are building stronger identity governance across customer and non-human systems, it is worth exploring.
This post draws on content published by Strivacity: CIAM certifications, passkeys, and accessibility. Read the original.
Published by the NHIMG editorial team on 2025-10-06.
NHI Mgmt Group — the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org