The model breaks wherever a required attribute is unavailable, inconsistent or not issued with the needed assurance. Institutions then fall back to documents, manual review or local exceptions, which creates uneven evidence quality and makes audit trails harder to defend.
Where national eIDs stop being enough for regulated attributes
National eIDs are strongest when the attribute needed for a decision is standardised, current and issued at the right assurance level. They break down when the institution needs attributes that sit outside the eID scheme, vary by jurisdiction, or must be verified to a higher bar than the wallet or identity provider can consistently supply.
That is why the failure is rarely just technical. It is usually a policy and operating-model mismatch: the regulated attribute exists somewhere, but not in a form that can be consumed reliably at onboarding, periodic review or exception handling.
What institutions fall back to when attributes are missing
Once a required attribute cannot be sourced cleanly from the national eID flow, teams tend to substitute documents, manual review, or locally defined exceptions. Those workarounds restore continuity, but they also reintroduce human judgement, uneven evidence quality and inconsistent treatment across customers, products or jurisdictions.
At that point, the institution is no longer operating one clean attribute model. It is operating several parallel ones, and that makes control design harder. A rule that looks enforceable in the eID journey may become partly manual in the edge cases, especially where the regulated attribute is sensitive, time-bound, or dependent on a source system the institution does not control.
Why auditability and consistency degrade
The biggest practical loss is defensibility. When evidence comes from multiple channels, the institution must prove not only that the attribute was checked, but also why one source was accepted over another and how exceptions were handled. That is much harder to defend if the process depends on screenshots, PDFs, email chains or local judgement.
Consistency also suffers across time. The same customer can receive different treatment if the attribute is missing on one occasion, stale on another, or asserted with different confidence by different issuers. Digital Identity, eID and Identity Wallets Guide is useful here because it shows how reusable credentials and wallets are intended to reduce this fragmentation, but only when the relying party can trust the underlying attribute model.
Risk and Threat Considerations
When regulated attributes are accepted through fallback paths, the control weakens in two directions: bad data can slip through, and good data can be applied inconsistently. That creates exposure to misrepresentation, weak provenance, and decisions that are difficult to evidence during challenge, audit or investigation.
Failure mechanism: The institution substitutes manual evidence or local exceptions for a standard attribute assertion, so assurance, freshness and provenance vary by case instead of being enforced by a common control path.
Impact: The business can end up with inconsistent onboarding outcomes, weaker audit trails, higher remediation cost, and a higher chance that the regulated attribute was not actually fit for the decision it supported.
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 CSF 2.0 set the technical controls, while ISO/IEC 27001:2022 defines the regulatory obligations.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST SP 800-53 Rev 5 | IA-8 — Identification and Authentication (Non-Organizational Users) | National eID attributes support external user identity and assurance decisions. |
| AU-2 — Event Logging | Fallback reviews and exceptions need traceable evidence for audit defense. | |
| Recommendation — Use IA-8 to require stronger identity proofing when regulated attributes drive access decisions. Log attribute exceptions and manual overrides to preserve defensible audit trails. | ||
| ISO/IEC 27001:2022 | A.5.15 — Access control | Attribute-driven decisions affect who may access regulated services and under what conditions. |
| Recommendation — Define access rules that stay consistent when eID attributes are missing or disputed. | ||
| NIST CSF 2.0 | PR.AA-05 — Identity Management, Authentication, and Access Control | The subject concerns assurance over identity attributes used in access decisions. |
| GV.RM-01 — Risk Management Strategy | Institutions need an explicit strategy for handling attribute gaps and exceptions. | |
| Recommendation — Enforce attribute-dependent access decisions with a controlled identity and access policy. Set a risk strategy for fallback evidence, exceptions, and assurance gaps in regulated attribute flows. | ||
Practitioner Guidance
What to verify: Check which regulated attributes are genuinely mandatory for the decision and whether each one can be sourced at the required assurance level, not just present in principle. If an attribute is only available through fallback evidence, treat that as a control design gap, not as a routine exception.
Decision rule: If the attribute can drive a regulated outcome, define in advance what happens when the national eID cannot supply it. Either require an alternate authoritative source, or route the case into a controlled manual process with explicit approval, retention, and review rules.
Practitioner takeaway: The real test is not whether the eID works for the happy path, but whether every required attribute has a defensible source of truth when the happy path fails.
Related resources from NHI Mgmt Group
- What breaks when access decisions rely on too many attributes?
- What breaks when institutions rely on manual data reconciliation for BCBS 239?
- What breaks when organisations rely only on ChatGPT enterprise controls to protect regulated data?
- What breaks when financial institutions rely on manual access reviews instead of governed workflows?