Who should be accountable when eIDAS 2 controls fail?

Why This Matters for Security Teams

When eIDAS 2 controls fail, the issue is rarely just technical. It is usually a governance failure across identity proofing, authentication, credential lifecycle, auditability, and third-party oversight. The regulated workflow may span legal, privacy, IAM, procurement, and operations, but accountability cannot be diffuse if evidence must stand up to supervisory review. Guidance from eIDAS 2.0 — EU Digital Identity Framework makes clear that trust in digital identity depends on controlled processes, not informal ownership.

Security teams often assume that if a platform is configured correctly, responsibility sits with the technical operator. That is a mistake. Control failure usually traces back to unclear ownership for policy decisions, exception handling, evidence retention, or supplier assurance. If the control owner is not explicit, no one is positioned to approve risk, challenge drift, or explain the failure to auditors or regulators. In practice, many security teams encounter ownership gaps only after a failed assurance review or disputed identity event, rather than through intentional control design.

How It Works in Practice

Operational accountability should be assigned to the function that owns the regulated outcome, not just the team that administers the tooling. In mature environments, that means one named business or security owner for the control, supported by IAM, legal, privacy, risk, and provider-management stakeholders. The technical team executes procedures, but the accountable owner defines the standard, accepts residual risk, and ensures the evidence chain is complete.

That model aligns well with the control discipline in NIST SP 800-53 Rev 5 Security and Privacy Controls, where responsibility for control implementation, monitoring, and assessment has to be explicit. For eIDAS 2 environments, the accountable owner should be able to show:

• who approved the identity workflow and its risk acceptance criteria
• who owns identity proofing, credential issuance, and recovery decisions
• who reviews provider performance and contractual control commitments
• who receives exceptions, incidents, and audit findings
• who can produce logs, attestations, and policy evidence on demand

This is especially important where trust services, wallet integrations, or cross-border identity flows are outsourced. A provider may operate part of the stack, but provider operation is not the same as accountability for compliance. The accountable function must maintain visibility into assurance reports, service changes, and incident notification obligations, and it must know when to pause a workflow that no longer meets policy.

That also means control ownership should be mapped into governance documents, not left in diagrams or runbooks. If the process crosses multiple teams, a RACI alone is not enough unless it is tied to named sign-off authority, escalation paths, and measurable control outcomes. These controls tend to break down when identity workflows are highly federated and evidence is split across multiple vendors because no single party can reconstruct the full decision trail.

Common Variations and Edge Cases

Tighter accountability often increases governance overhead, requiring organisations to balance clear ownership against the speed of change. That tradeoff is real, especially where identity services are delivered through shared platforms or managed providers. Current guidance suggests that the accountable owner should still be singular, even if execution is distributed across several teams.

There is no universal standard for every operating model, but the edge cases are predictable. In group-wide identity platforms, accountability may sit with an enterprise IAM or digital identity function. In outsourced trust service arrangements, the customer organisation still owns the regulatory outcome for its own workflow, even if the provider performs technical operations. In privacy-sensitive journeys, legal or data protection roles may need formal approval rights, but that does not replace the need for a control owner who can be challenged when the control fails.

For NHI or agentic workflows that rely on automated identity actions, accountability becomes even more important because machine speed can hide weak approvals and stale policy. The practical question is not who pressed the button, but who was responsible for ensuring the system could not act outside its authority. Where that answer is unclear, the organisation will struggle to prove compliance, limit blast radius, or learn from the failure.

Related resources from NHI Mgmt Group

• What is the difference between human IAM controls and NHI governance?
• When should organizations review access controls?
• Who is accountable when administrative access controls fail in CMMC assessments?
• Who is accountable when identity security controls fail across team boundaries?