Should teams treat eIDAS 2 as an IAM issue or a privacy issue?

Why eIDAS 2 is not just an IAM question or just a privacy question

eIDAS 2 sits at the boundary between identity proofing, trust services, and data protection. The operational question is not whether it belongs to IAM or privacy, but how the same workflow will satisfy both control objectives at once. That means governance must cover identity assurance, attribute handling, consent, disclosure minimisation, logging, and auditability as one system.

For practitioners, the practical test is whether the control decision changes when the focus shifts from authentication to data minimisation. If it does, the programme is already spanning IAM and privacy, whether the org charts reflect that or not.

A useful way to frame it is that eIDAS 2 defines how identity evidence is created, exchanged, and relied upon, while privacy determines how much of that evidence should be disclosed, retained, and protected. The same wallet, verifier, and trust service flows can therefore create both access risk and privacy risk if they are designed in isolation. The eIDAS 2.0, EU Digital Identity Framework is the primary legal anchor for that shared operating model.

Where IAM responsibilities and privacy responsibilities overlap

IAM teams usually own identity proofing, credential issuance, assurance levels, relying-party trust, and authentication policy. Privacy teams usually own lawful basis, purpose limitation, minimisation, retention, and user rights. Under eIDAS 2, those duties collide in the same user journey because a wallet or trust service may reveal identity attributes that are sufficient for one transaction but excessive for another.

This overlap matters most where verifier design drives disclosure. If the verifier asks for a full identity document when a selective attribute would do, the issue is not only privacy leakage, it is also a poor access design choice because the relying party is demanding more identity evidence than the use case requires. The EU General Data Protection Regulation (GDPR) becomes operationally relevant wherever personal data processing, biometric evidence, or data protection by design are part of the same flow.

In practice, teams should treat wallet claims, verification rules, and consent screens as linked control points. If IAM validates the transaction but privacy cannot explain the data minimisation decision, the implementation is incomplete. If privacy approves the disclosure model but IAM cannot attest to identity assurance or relying-party trust, the implementation is also incomplete.

How to organise ownership without creating gaps

The cleanest operating model is joint ownership with clear control boundaries. IAM should own identity assurance, trust establishment, and authentication mechanics. Privacy should own disclosure policy, retention, and rights handling. Compliance or legal should arbitrate the regulatory interpretation when identity evidence has cross-border or statutory implications. That division avoids a common failure mode, where each team assumes the other is covering the control that actually breaks the workflow.

At scale, the biggest risk is fragmented evidence. A wallet journey can generate proof of identity, proof of attribute, consent evidence, verifier logs, and trust-service records. If those artifacts are spread across separate teams, no one can reconstruct who relied on what, when, and under which policy. That is why a shared evidence model matters more than a shared terminology exercise. The Digital Identity, eID and Identity Wallets Guide is a useful internal reference for the wallet and verifiable-credential side of that model.

Practitioners should also expect privacy and IAM controls to interact during exception handling. A temporary exemption, fallback credential, or manual verification path may be acceptable for access continuity, but it still needs a data-minimisation and retention decision. If exceptions are not logged in a way that both teams can review, the programme will accumulate unseen policy drift.

Risk and Threat Considerations

eIDAS 2 creates risk when organisations treat identity assurance and privacy protection as separate compliance tracks. That split can produce excessive data disclosure, weak evidence of user consent, inconsistent reliance decisions, and audit gaps when a verifier, wallet provider, or relying party cannot reconstruct the full transaction chain.

Failure mechanism: The control fails when identity proofing, attribute release, trust validation, and privacy decisions are implemented by different teams without a shared evidence trail or common policy model. The result is either over-disclosure of personal data or under-validated reliance on an identity assertion.

Impact: Organisations can end up with privacy breaches, failed audits, unusable trust relationships, or access decisions that are strong on authentication but weak on lawful processing and minimisation. Over time, that undermines both regulatory confidence and operational trust in the wallet ecosystem.

Practitioner Guidance

What to prioritise: Build one decision map for the full journey, from identity proofing to attribute disclosure to verifier reliance. The key question is not who owns the regulation, but who can prove the end-to-end control outcome.

What to verify: Verify that every high-risk workflow has an evidence trail showing what was disclosed, why it was needed, who relied on it, and how long it is retained. If you cannot reconstruct that path, you do not yet have a workable eIDAS 2 operating model.

Decision rule: If a use case can succeed with fewer attributes or a weaker correlation to a person, prefer the narrower disclosure path and document the trade-off. If the use case depends on strong legal identity, raise assurance and audit requirements rather than pushing the burden onto privacy exceptions.

Practitioner takeaway: eIDAS 2 should be run as a joint identity and privacy control system, because the security value comes from proving exactly who or what was trusted, while the privacy value comes from limiting what was revealed to make that trust possible.

Related resources from NHI Mgmt Group

• Should retail teams treat secrets architecture as a continuity issue or an IAM issue?
• Should teams treat application rationalisation as an IAM issue or a finance issue?
• When should privacy and IAM teams treat non-sensitive data as sensitive?
• When should privacy and cloud teams treat residency drift as a compliance issue?