Because a register can prove eligibility, but it cannot authenticate the party sending a request. Certificates add the cryptographic proof that the requester controls the private key linked to a trusted identity. Without that proof, the wallet can confirm name and status, but not the authenticity of the session origin.
Why the register is not enough on its own
A national register can tell a wallet that a party is eligible, recognised, or registered to participate. It does not, by itself, prove that the live request came from that party or that the session has not been intercepted or replayed. The certificate adds the cryptographic binding between the requester and the trusted identity, which is what turns eligibility into authenticated interaction.
That distinction matters because wallet flows are not just about who exists in the ecosystem, but about who is actually on the other end of the connection at request time. A register supports discovery and trust decisions, while certificate-based authentication supports session-level proof of possession and helps the wallet distinguish a legitimate relying party from an impostor using the same published details.
The practical consequence is that a register can support policy, onboarding, and allowlisting, but it cannot replace mutual authentication where the protocol needs to verify origin. In secure wallet architectures, the register answers “should this party be trusted to participate?”, while the certificate helps answer “is this specific requester the one that was approved?”
What certificates add to wallet trust decisions
Relying party certificates provide cryptographic assurance that the requester controls the private key associated with the trusted identity. That proof is materially different from registry presence, because registry data is usually static governance data while certificate validation is an active protocol control. The wallet can therefore rely on the register for identity enrollment and on the certificate for live authentication.
This is especially important when a wallet must evaluate an incoming request from a remote service or verifier. A certificate can be checked against the trust chain, expiry, revocation status, and binding to the expected party identity. Those checks give the wallet more than name or status, they give it confidence that the connection endpoint is authorised to speak for the registered party at that moment.
For practitioners, the key design point is separation of concerns. Registration tells you which parties belong in the ecosystem, but certificates tell you which requester can prove control of the credential material needed to establish the session. That is why certificate handling belongs in the technical trust layer, not just the policy layer.
What breaks when you rely on the register alone
If a wallet trusts the register as the only source of truth, a malicious or misconfigured requester can present registry-visible details without proving possession of the corresponding private key. That creates a gap between administrative identity and cryptographic identity, which is exactly where session hijacking, impersonation, and replay-style abuse become possible.
In that failure mode, the wallet may correctly confirm that the relying party name exists, but still be unable to confirm that the current request originated from that party. The result is a trust model that is good for eligibility checks but weak for request authenticity, especially when the channel is exposed to network attackers, proxy abuse, or credential theft. The wallet should therefore treat the register as necessary context, not sufficient proof.
Risk and Threat Considerations
When a wallet accepts registry presence as proof of authenticity, the main risk is impersonation of an otherwise legitimate party. That weakens the trust boundary around the session itself, not just around onboarding, and can expose token issuance, consent decisions, or attribute release to an unauthenticated requester.
Failure mechanism: An attacker or misbound client can use published or copied registry identity data to initiate a request without proving control of the private key linked to that identity. The wallet then has policy confidence, but not cryptographic assurance, so the trust decision can be fooled at the moment of connection.
Impact: The wallet may deliver data, approvals, or verifiable interactions to the wrong party, which can lead to unauthorised access, consent abuse, or disclosure of identity attributes. In stronger deployments, certificate validation also supports revocation and expiry handling, so losing that layer can leave stale trust paths open longer than intended.
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, NIST SP 800-57 and NIST SP 800-63 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST SP 800-53 Rev 5 | IA-9 — Identification and Authentication (Non-Organizational Users) | Wallet relying party certs authenticate external counterparties. |
| IA-5 — Authenticator Management | Certificate trust depends on key and certificate lifecycle control. | |
| SC-12 — Cryptographic Key Establishment and Management | Private-key possession underpins the certificate proof used by the wallet. | |
| Recommendation — Require cryptographic authentication for the relying party before trusting the session. Manage certificate issuance, renewal, revocation, and replacement as a controlled lifecycle. Protect the private key and enforce secure key establishment and handling. | ||
| NIST SP 800-57 | Key Management Lifecycle | Certificate assurance depends on key lifecycle, cryptoperiod, and revocation discipline. |
| Recommendation — Apply disciplined key lifecycle controls so certificate-bound trust remains current. | ||
| NIST SP 800-63 | Digital Identity Guidelines | The question concerns authenticated digital interactions and proof of control. |
| Recommendation — Use authenticated federation and proof-of-possession mechanisms where session origin must be trusted. | ||
Practitioner Guidance
What to verify: Treat the national register as the source for eligibility and identity metadata, then verify that the relying party also presents a valid certificate bound to the same identity and trust anchor before accepting the request. If the protocol does not require that proof, assume the session origin is weaker than the registry record suggests.
Decision rule: If the action depends on knowing who is on the other end of the live request, require certificate-based authentication or an equivalent cryptographic proof, not just registry lookup. If the action is only about coarse eligibility or discovery, the register may be enough for that narrower step, but not for session trust.
Practitioner takeaway: A register establishes who is allowed to participate; a certificate establishes who is actually speaking right now. Secure wallet design needs both, because policy trust without cryptographic proof leaves the session origin unresolved.