eIDAS 2 gives users more control over which attributes they share, but that flexibility also increases governance demands. If organisations rely on more data than necessary, they raise privacy risk and compliance exposure. The safer model is attribute minimisation, purpose limitation, and clear rules for what third parties can use, retain, and verify under GDPR-aligned controls.
Why Shared Attributes Need Tighter Governance Under eIDAS 2
eIDAS 2 makes identity data more portable and user-directed, which is valuable but operationally sensitive. When a relying party can receive more attributes, or receive them more selectively, the governance burden moves from simple login assurance to attribute-level control: minimisation, lawful use, retention, verification scope, and downstream sharing rules. The practical challenge is that shared attributes often become reusable trust signals across systems, so weak controls can amplify privacy and compliance exposure quickly.
The regulatory direction is set by the eIDAS 2.0, EU Digital Identity Framework, but the control problem is operational: once attributes can be shared more flexibly, organisations must prove they only collect what they need and only use it for the declared purpose. In practice, many failures begin when teams treat attribute receipt as a blanket permission to repurpose the data across onboarding, screening, analytics, and support workflows.
For teams that manage shared identity attributes at scale, the governance question is less about whether the data is authenticated and more about whether each attribute is still justified after it leaves the identity wallet.
How Attribute Sharing Works in Practice
eIDAS 2 increases the number of situations where organisations will see attributes without owning the full identity lifecycle. That changes the control pattern. Instead of asking only whether a person is who they claim to be, teams also need to define which attributes are acceptable for which business action, whether the attribute is current enough, and whether a third party is allowed to retain it after the transaction ends.
Attribute minimisation: request only the fields needed for the specific decision, not a broad profile that can be reused later.
Purpose limitation: bind each attribute to a documented use case so downstream teams cannot silently expand its use.
Verification scope: decide which attributes need strong assurance, which can be self-asserted, and which must be checked against an authoritative source.
Retention and reuse rules: define whether the attribute may be stored, hashed, cached, or re-shared after the original transaction.
This is also where implementation discipline matters. A shared attribute can be technically valid yet still be a governance problem if it outlives the purpose for which it was collected. Attribute-level access rules, logging of consent and disclosure events, and periodic review of third-party consumption are what keep the model aligned with GDPR-style expectations rather than drifting into data overcollection.
NHIMG’s Ultimate Guide to NHIs reports that 97% of NHIs carry excessive privileges, which is a useful reminder of how quickly trust expands when controls are not scoped tightly. These controls tend to break down when shared attributes are copied into multiple internal systems, because each copy creates a new place where purpose and retention can be forgotten.
Common Variations and Edge Cases
Tighter attribute control often adds friction to onboarding, verification, and customer support, so organisations have to balance user convenience against the risk of overexposure. The hardest cases are usually not the core identity proofing flows, but the secondary uses that emerge after the attribute is already in the organisation’s hands.
One common edge case is when a relying party needs enough data to satisfy compliance, but not enough to justify broad storage or reuse. Another is cross-border or cross-entity sharing, where each recipient may have a different lawful basis, retention period, or assurance standard. Current guidance suggests treating those differences explicitly rather than assuming a single attribute policy can cover every downstream consumer.
A second edge case is selective disclosure. It reduces exposure, but only if the receiving system is built to respect partial claims and avoid compensating by asking for more attributes than the transaction actually needs. That is where policy design and system design must align.
Teams should expect the most trouble where business owners equate “available to share” with “available to keep.” In practice, attribute governance fails when retention and reuse are left to individual application teams instead of being enforced centrally.
Risk and Threat Considerations
The main risk is not just privacy leakage, it is trust expansion. Once shared attributes are copied, retained, or recombined, they can be used beyond the original purpose, increasing regulatory exposure and making future disclosure harder to control. That creates both compliance risk and a practical attack surface for misuse, excessive profiling, and weak third-party handling.
Failure mechanism: organisations often over-collect “just in case” attributes, then allow downstream systems to repurpose them for onboarding, fraud checks, analytics, or support. Each reuse increases the chance that retention, consent, and disclosure rules drift out of sync with the original eIDAS 2 transaction.
Impact: the result can be unlawful processing, unnecessary exposure of personal data, weaker auditability, and a wider blast radius if a third party mishandles or compromises the shared attributes.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
NIST CSF 2.0 and CIS Controls v8 set the technical controls, while EU AI Act define the regulatory obligations.
| Framework | Control / Reference | Relevance |
|---|---|---|
| EU AI Act | EU AI Act | Relevant as an EU digital governance benchmark for controlled data use and accountability. |
| Recommendation — Align attribute-sharing governance to the applicable EU digital compliance duties. | ||
| NIST CSF 2.0 | PR.AC-1 — Identity Management, Authentication and Access Control | Applies to controlling who can receive and use shared identity attributes. |
| GV.RM-1 — Risk Management Strategy | Supports formal governance of privacy and compliance exposure from shared attributes. | |
| Recommendation — Limit attribute access to the minimum set needed for each authorised transaction. Document attribute-sharing risk acceptance and review it as a governed control decision. | ||
| CIS Controls v8 | 6.3 — Data Protection | Directly supports minimisation, retention limits and handling rules for shared attributes. |
| Recommendation — Classify shared attributes and enforce retention and handling restrictions. | ||
Practitioner Guidance
What to prioritise: define an attribute-by-attribute policy before integration work begins. The key decision is not whether the attribute can be shared, but whether each recipient can justify collection, retention, and reuse for a specific business purpose.
What to verify: check that application owners can show where each shared attribute is used, how long it is kept, and who can access it after receipt. If they cannot produce that inventory, the control is not mature enough for production reliance.
Decision rule: if a downstream team wants to keep an attribute for convenience rather than necessity, treat that as a governance exception and require explicit approval. Convenience-based retention is where attribute sprawl usually begins.
Practitioner takeaway: eIDAS 2 shifts the challenge from proving identity to controlling the lifecycle of shared attributes, and the safest programmes are the ones that make minimisation and downstream purpose boundaries non-negotiable.
Related resources from NHI Mgmt Group
Deepen Your Knowledge
Reviewed and updated by the NHIMG editorial team on September 14, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org
