They do not remove it from the relying party. The organisation still owns the risk assessment, the compliance decision, and the audit trail, even when a certified provider performs the identity step. That division is deliberate, because outsourcing verification is not the same as outsourcing accountability.
How the accountability split works in practice
digital identity schemes usually separate identity assurance from business accountability. A certified provider may verify a person or organisation, but the relying party still decides whether that assurance is sufficient for the transaction, the risk, and the regulatory obligation. That is why the relying party remains responsible for the decision record, even when it does not run the verification step itself.
That division matters because accountability attaches to the party that accepts the identity claim and acts on it. The provider can attest that a check was performed, but it does not inherit the relying party’s duty to decide whether the claimed identity should be trusted for a specific purpose, context, or level of assurance.
What changes when verification is outsourced
Outsourcing the identity step changes the operating model, not the liability chain. The relying party should treat the provider’s output as one control input among several, alongside its own policy, fraud rules, compliance criteria, and audit evidence. In practice, the relying party still needs to know why the identity result was accepted, what assurance level was used, and what exceptions were allowed.
That is especially important where a scheme supports selective disclosure, reusable credentials, or cross-border identity acceptance. Those features can reduce friction, but they also make the relying party’s own acceptance rules more important, because the organisation must be able to justify the specific trust decision it made at the point of use.
Why traceability and recordkeeping still sit with the relying party
When something goes wrong, the key question is rarely only “was the identity checked?” It is usually “who decided that this check was good enough for this action?” The answer needs to be visible in the organisation’s audit trail, because accountability depends on being able to reconstruct the decision, the evidence used, and any override or exception path.
That is why schemes like this only work cleanly when the relying party keeps its own records of acceptance criteria, assurance mapping, and exception handling. The provider may supply a verification event, but the relying party must retain the evidence that links that event to its own internal control decision. NHIMG’s Ultimate Guide to NHIs — Regulatory and Audit Perspectives covers the same accountability logic for auditability and governance in identity-heavy environments.
Risk and Threat Considerations
Accountability gaps appear when organisations assume that a certified identity provider has taken over the whole duty of care. That assumption can lead to weak acceptance rules, poor exception tracking, and an audit trail that proves a verification happened but not that the relying party made a defensible decision.
Failure mechanism: The relying party treats provider certification as a substitute for its own policy, so an identity event is accepted without a documented link to the transaction risk, assurance threshold, or exception approval. That creates a governance gap even when the underlying verification service functioned correctly.
Impact: If a disputed onboarding, access grant, or high-risk transaction is later reviewed, the organisation may not be able to show who accepted the identity claim, on what basis, or under which internal control. The result is weaker non-repudiation, harder incident investigation, and greater exposure during audit or regulatory review.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
NIST SP 800-53 Rev 5 and NIST SP 800-63 set the technical controls, while ISO/IEC 27001:2022 defines the regulatory obligations.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST SP 800-53 Rev 5 | AU-6 — Audit Record Review, Analysis, and Reporting | Decision traceability is central to proving why an identity result was accepted. |
| IA-2 — Identification and Authentication (Organizational Users) | The question turns on who authenticates and who remains accountable for the access decision. | |
| Recommendation — Retain and review identity acceptance evidence so each trust decision can be reconstructed. Require authenticated evidence and explicit acceptance rules before granting access or trust. | ||
| ISO/IEC 27001:2022 | A.5.15 — Access control | The relying party still controls how identity assurance is accepted into access decisions. |
| Recommendation — Define and enforce access acceptance criteria that remain owned by the relying party. | ||
| NIST SP 800-63 | 5.2.2 — Identity Proofing | Digital identity schemes depend on proofing assurance, but acceptance remains a relying-party decision. |
| 6.3 — Federation Assurance | Federated identity shifts verification, yet the relying party still bears the trust decision. | |
| Recommendation — Map proofing assurance to internal acceptance thresholds before relying on external identity. Set federation acceptance rules that preserve local accountability for each transaction. | ||
Practitioner Guidance
What to verify: Confirm that your reliance policy explicitly states which provider artefacts are acceptable, what assurance level is required for each transaction type, and who signs off on exceptions. If the policy cannot be traced to a decision record, the control is weaker than it looks.
What good looks like: The provider’s verification result, the relying party’s acceptance rule, and the final business decision all appear in the same evidence chain. A reviewer should be able to answer, without guesswork, why the identity step was sufficient for this specific use case.
Practitioner takeaway: A digital identity scheme can outsource verification, but it cannot outsource the organisation’s duty to justify trust, keep the audit trail, and own the consequence when the decision is wrong.
Related resources from NHI Mgmt Group
- Guide: Digital Identity, eID and Identity Wallets Guide
- Who should be accountable when a biometric identity platform holds large-scale sensitive data and something goes wrong?
- When does a machine identity become a compliance problem?
- Why is it important to integrate identity and data governance?
- When does secret exposure become a broader identity risk?