SCA proves a transaction met a minimum authentication requirement, while identity assurance proves the institution can trust the person, device, and context behind the decision. PSD3 depends on both, but the article shows that assurance is the broader control plane because it governs recovery, delegation, fraud detection, and API access as well as sign-in.
What SCA actually proves, and what it does not
Strong Customer Authentication is a transaction-level control. In PSD3, it answers a narrow question: was the action approved under the required authentication standard for that event? It does not, by itself, tell you whether the person, device, channel, or session was trustworthy enough to support the broader decision. That is why SCA is necessary, but not sufficient, for modern fraud and access governance.
SCA is usually evaluated at the point of challenge, approval, or exemption. Its value is that it creates a minimum bar for interactive trust, often through multi-factor or other strong auth methods. Its limitation is equally important: a valid SCA event can still sit inside a weak account recovery flow, a compromised device, a poisoned session, or an over-permissive API path.
For teams mapping controls to the regulation, NIST SP 800-63 Digital Identity Guidelines is a useful reference point because it separates authentication strength from broader identity assurance outcomes. That distinction helps avoid treating one successful login challenge as proof that the surrounding identity lifecycle is trustworthy.
Why identity assurance is broader than sign-in assurance
Identity assurance is the wider control plane. It asks whether the institution can trust the identity being used, not just whether a single authentication event passed. In PSD3 terms, that means confidence in the person, the device, the enrolment trail, the recovery path, the delegated access model, and the context in which the decision was made. It is the difference between proving an event and proving an identity relationship.
This broader view matters because many losses happen outside the sign-in moment. Account recovery abuse, SIM swap style takeover, session theft, social engineering of support teams, and fraud routed through legitimate APIs can all bypass a narrow SCA mindset. Assurance is therefore tied to governance over lifecycle, fraud detection, and access decisions, not only to front-door authentication.
The regulatory direction also aligns with stronger identity frameworks such as eIDAS 2.0, the EU Digital Identity Framework, which emphasises trusted digital identity and cross-border verification. For readers building bank or payments controls, NHIMG’s Financial Services Identity Security Guide places PSD3, SCA, and identity obligations in the same operational frame.
How PSD3 changes the control conversation
PSD3 does not make SCA obsolete. It makes SCA one control inside a larger assurance model. Practically, that means payment firms need to think about step-up authentication, recovery hardening, delegated authority, fraud signals, and API access together. A good design can satisfy SCA while still failing identity assurance if it cannot explain who is acting, from where, under what privileges, and with what recovery evidence.
That is where the distinction becomes operational. SCA can answer “was this transaction challenged correctly?” while assurance answers “should this entity, device, or session be trusted enough to keep making decisions?” If the second question is weak, the first can become a compliance checkbox rather than a risk control.
Identity assurance also reaches beyond end-user sign-in into machine and application trust. In modern banking architectures, service-to-service calls, payment APIs, and delegated flows may be as important as human authentication. NHIMG’s Ultimate Guide to NHIs, What are Non-Human Identities is useful here because it shows how identity decisions extend into workload, service, and API relationships that SCA alone never covers.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP API Security Top 10 addresses the attack surface, NIST SP 800-63, NIST CSF 2.0 and NIST SP 800-53 Rev 5 set the technical controls, and ISO/IEC 27001:2022 defines the regulatory obligations.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST SP 800-63 | Digital Identity Guidelines | Identity assurance and authenticators are central to the SCA versus assurance distinction. |
| Recommendation — Use identity assurance and authenticator assurance levels to separate login strength from broader trust. | ||
| NIST CSF 2.0 | GV.OV-01 — Outcomes are Measurable | PSD3 control effectiveness depends on measuring assurance, not only successful authentication events. |
| Recommendation — Define measurable assurance outcomes for recovery, delegation, and step-up decisions. | ||
| NIST SP 800-53 Rev 5 | IA-5 — Authenticator Management | SCA depends on managed authenticators, especially rotation, revocation, and lifecycle control. |
| Recommendation — Manage authenticator lifecycle so SCA depends on controlled credentials, not static trust. | ||
| OWASP API Security Top 10 | API2 — Broken Authentication | PSD3 identity assurance must cover API access paths where broken authentication undermines trust. |
| Recommendation — Harden API authentication paths that can bypass user-facing SCA controls. | ||
| ISO/IEC 27001:2022 | A.5.16 — Identity management | Assurance depends on governed identity lifecycle, ownership, and trust relationships across channels. |
| Recommendation — Tie payment identity assurance to governed identity management and lifecycle evidence. | ||
Practitioner Guidance
What to prioritise: Treat SCA as the event control and identity assurance as the operating model. If you only measure challenge success rates, you will miss the real failure modes in recovery, delegated access, and post-authentication abuse.
What to verify: Confirm that every high-value payment flow has traceable assurance evidence for enrolment, recovery, device binding, and step-up decisions. If those artefacts do not exist, the institution is relying on sign-in strength without proving identity trust.
Decision rule: If a flow can move money, alter payee data, or grant API access, require assurance evidence beyond SCA before calling the control effective. Where the system cannot produce that evidence, treat the gap as a control design issue, not just an authentication issue.
Practitioner takeaway: PSD3 pushes teams to stop equating “strong login” with “trusted identity”; the mature control is the one that can prove both the transaction challenge and the broader trust story behind it.
Related resources from NHI Mgmt Group
- What is the difference between patching a vulnerability and reducing identity blast radius?
- What is the difference between attack surface management and NHI governance?
- What is the difference between reviewing human access and reviewing NHIs?
- What is the difference between role-based access and API key governance for NHI security?
Deepen Your Knowledge
Free weekly newsletter
Subscribe to the NHI & AI Identity Journal
The latest on NHI and Agentic AI security – articles, research, breaches, news and events every week.
Bonus 33% off our NHI Course when you subscribe.
Reviewed and updated by the NHIMG editorial team on October 11, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org