Centralised attribute stores create a larger blast radius if data is compromised, misused, or over-shared. Even if the wallet improves user convenience, concentration turns privacy loss and fraud exposure into systemic risks rather than isolated events. Practitioners should design for minimal retention and selective disclosure so the data model does not amplify impact.
How centralised attribute stores change the security model
When a digital identity system concentrates age, address, status, device, entitlement, or preference data into one store, it creates a single point where compromise, misuse, or accidental overexposure can affect many relying parties at once. The problem is not only theft; it is also correlation. More attributes make it easier to link activities across services, which reduces compartmentalisation and increases the cost of a privacy failure.
That shifts the design goal from “can the wallet present data?” to “how little data must exist, and how narrowly can it be disclosed?” Selective disclosure, minimisation, and short retention matter because the attribute store becomes a high-value target and a high-impact dependency. eIDAS 2.0’s wallet model is designed around this kind of controlled disclosure, not broad attribute replication; see eIDAS 2.0, the EU Digital Identity Framework.
Practically, centralisation also changes trust boundaries. Once a wallet or hub becomes the place where multiple proofs, claims, and usage records converge, the system’s privacy posture depends on governance around retention, consent, disclosure scope, and who can query the store. A design that is convenient for users can still be fragile if it makes re-identification, profiling, or bulk exfiltration much easier.
Why the blast radius grows faster than the attribute list
The increase in impact is not linear. Each additional attribute can strengthen identity proofing, but it also adds another way to infer a person’s profile, target fraud, or abuse a downstream service. In a central store, a single compromise can expose enough linked data to enable account takeover, synthetic identity fraud, or highly targeted social engineering, even if no single attribute seems sensitive on its own.
That is why “just one more field” is usually a poor security trade-off. The more attributes are retained, the more likely a system is to accumulate stale, duplicated, or unnecessary data across wallets, brokers, and relying parties. If the model does not enforce purpose limitation and disclosure boundaries, the system can become a privacy amplifier rather than a privacy-preserving control.
Attribute concentration also creates operational dependency. If a wallet or identity broker becomes the authoritative source for many services, any data quality error, access error, or policy mistake can propagate widely. Readers should treat this as an architecture problem, not only a data-model problem.
How practitioners should reduce concentration risk
Good practice is to minimise the attribute set at rest, issue only the claims needed for the transaction, and avoid building a universal profile that every relying party can query. Prefer selective disclosure mechanisms, short-lived presentations, and explicit release policies so the system does not expose more than the current use case requires.
Where the platform supports it, separate identity proofing data from routine authentication data and from service-specific attributes. That separation makes compromise harder to convert into broad correlation. It also gives teams clearer decisions about retention, revocation, and deletion when a user changes context or withdraws consent.
If a service insists on broad attribute access, treat that as a design exception and ask whether the relying party truly needs the data or is simply benefiting from convenience. The correct control is usually not “collect more for later,” but “disclose less by default.”
Risk and Threat Considerations
Centralised attribute stores create a high-value target for attackers and a high-impact failure point for defenders. The main risk is not just breach exposure, but cross-service correlation, fraud enablement, and large-scale privacy harm when one compromise reveals enough linked data to impersonate, profile, or track users across multiple contexts.
Failure mechanism: Excessive attribute concentration, weak disclosure boundaries, or over-retention turns one identity record into a reusable source of sensitive context, so compromise or misuse of the store propagates to many dependent services at once.
Impact: A single event can produce systemic privacy loss, larger fraud blast radius, broader re-identification risk, and wider downstream trust failure than isolated, service-specific records would create.
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 sets the technical controls, while ISO/IEC 27001:2022 and GDPR define the regulatory obligations.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST SP 800-53 Rev 5 | IA-5 — Authenticator Management | Covers controlling identity-bearing material lifecycle that should not be over-centralised. |
| AC-6 — Least Privilege | Supports minimising which services may access centralised identity attributes. | |
| PT-3 — Personally Identifiable Information Processing Purposes | Applies to limiting collection and disclosure of identity attributes to defined purposes. | |
| Recommendation — Limit retained attributes and rotate or revoke presentations and secrets on a strict lifecycle. Restrict attribute access to the smallest set of functions that need it. Bind attribute use to the specific purpose and refuse broad reuse. | ||
| ISO/IEC 27001:2022 | A.5.12 — Classification of information | Material because attribute centralisation depends on classifying which identity data is sensitive. |
| Recommendation — Classify identity attributes so retention and disclosure controls match sensitivity. | ||
| GDPR | Art. 5 — Principles relating to processing of personal data | Directly relevant to minimisation, purpose limitation, and storage limitation for centralised attributes. |
| Recommendation — Collect only the attributes needed for the stated purpose and keep them no longer than necessary. | ||
Practitioner Guidance
What to prioritise: Start by classifying which attributes are genuinely required for proof, which are only convenience data, and which can be replaced by verifiable assertions or selective disclosure. That distinction drives the blast radius more than the wallet brand or protocol choice.
What to verify: Check whether the store retains data beyond the transaction need, whether relying parties can request more than they should, and whether deletion or revocation actually removes future disclosure paths. If you cannot explain why an attribute must persist, it probably should not.
Decision rule: If an attribute can identify, profile, or authenticate a person outside the immediate transaction, treat it as high-impact data and constrain retention and access before broadening functionality.
Practitioner takeaway: A digital identity system becomes risky when convenience is achieved by centralising reusable personal context; the safer pattern is to keep identity useful for the transaction while making cross-context correlation harder, not easier.
Related resources from NHI Mgmt Group
- What happens when organisations try to manage enterprise identity security with too many point tools?
- What happens when access is managed across too many disconnected systems?
- What happens when organisations modernise systems but ignore digital identity and user readiness?
- How should security teams simplify identity and access management when they have too many disconnected systems?