AEPD sanction puts digital ID governance and GDPR accountability in focus

At a glance

What this is: Spain’s AEPD sanctioned Yoti over its Digital ID app, creating a governance and compliance dispute rather than a confirmed breach.

Why it matters: It matters because identity verification platforms sit at the boundary between IAM, privacy, and regulated personal data processing, where control scope and accountability must be demonstrable.

By the numbers:

• 72% of organisations have experienced or suspect they have experienced a breach of non-human identities , 46% confirmed, 26% suspected.

👉 Read Yoti's statement on the AEPD sanction over its Digital ID app

Context

Digital identity platforms process personal data at the point where verification, authentication, and privacy obligations overlap. When a regulator sanctions an identity provider, the issue is usually not whether the app is technically available, but whether the processing model, user notices, and legal basis are sufficiently controlled and evidenced. In this case, the primary question for practitioners is GDPR governance, not breach response.

For IAM, IGA, and privacy teams, the operational lesson is that identity verification services must be governed like regulated data-processing systems, not just customer-facing apps. That means mapping collection, purpose limitation, retention, and review obligations clearly enough that internal controls can withstand regulatory challenge. The intersection with NHI is indirect but real: the same governance discipline should extend to API keys, backend services, and other machine identities supporting the identity platform.

Key questions

Q: What breaks when digital identity apps are treated as ordinary consumer apps?

A: The main failure is governance drift. Identity verification apps process regulated personal data, often across multiple processors and backend services, so consumer-style product management is not enough. Teams need documented lawful basis, retention rules, access governance, and audit evidence. Without that, the app may be technically secure but still non-compliant under privacy law.

Q: Why do digital ID platforms create GDPR accountability pressure?

A: Because they sit at the intersection of identity verification, personal data processing, and external trust. Regulators expect organisations to justify collection, limit use, and show control over storage and access. If the platform cannot evidence those choices, accountability shifts from the vendor narrative to the operator’s control environment.

Q: How do security teams know whether privacy controls are actually working?

A: Look for evidence that discovery, classification, DSR routing, and consent enforcement update when the environment changes. If privacy artifacts only refresh on calendar cadence or after manual chases, the programme is operating on stale assumptions. Working controls produce current inventory, traceable approvals, and audit-ready logs without depending on memory.

Q: Who is accountable when a digital identity app is sanctioned?

A: Accountability usually sits with the organisation operating the service, even if a vendor provides the platform or components. Privacy, IAM, application security, and legal ownership must be explicit because regulators assess the actual processing chain, not just the product label. Shared responsibility does not remove the need for a named control owner.

Technical breakdown

Regulatory findings in digital identity apps

A sanction from a data protection authority usually indicates a mismatch between how a digital identity system processes personal data and how that processing was disclosed, justified, or controlled. In identity verification, the core issues are purpose limitation, consent or lawful basis, retention, and access governance across the application stack. Even when no breach occurs, a regulator can still find infringements if the data lifecycle is not aligned to the stated service model. For identity platforms, compliance is therefore an operational control problem, not just a legal one.

Practical implication: map every data flow in the identity app and tie it to a documented lawful basis, retention rule, and owner.

Why app-level security and data-protection compliance are different

An identity app can be secure from an availability or integrity standpoint and still fail data-protection obligations. Security controls answer whether systems are protected from unauthorised access or tampering, while privacy controls ask whether collection, use, and disclosure are justified and minimised. This distinction matters because many digital ID services rely on multiple processors, embedded SDKs, and backend services that expand the processing surface beyond the user interface. Governance needs both control families, and they need evidence.

Practical implication: assess security controls and privacy controls separately, then reconcile them in one control register.

Machine identities that support identity verification

Digital identity services depend on service accounts, API keys, certificates, and other non-human identities to move data between front-end apps, verification engines, and storage systems. Those machine identities do not create the regulatory issue by themselves, but they do create the attack surface that can undermine the trustworthiness of the platform. If access scope, key rotation, or offboarding are weak, the identity service can expose personal data even when the app’s user-facing security looks sound.

Practical implication: inventory backend NHIs supporting the identity stack and govern them with the same discipline as user access.

NHI Mgmt Group analysis

Digital identity governance is now a compliance control, not a branding exercise. A regulator sanction against an identity app shows that trust in digital identity is built on evidence of lawful processing, not on claims of security. For IAM and privacy teams, the control question is whether the platform can prove collection, purpose, and retention discipline under review. Practitioners should treat identity verification services as regulated processing environments.

Privacy and IAM failures often sit in the same workflow but are not the same failure. The app may remain technically secure while the organisation still breaches data-protection obligations through poor notice, over-collection, or weak processing governance. That distinction matters because security controls can pass while privacy controls fail. Practitioners should align legal basis, consent flows, and access governance in one operating model.

Machine identity governance is part of identity platform accountability. Identity services depend on backend service accounts, tokens, and certificates that can expand exposure if they are not tightly scoped and lifecycle-managed. That creates a non-human identity layer inside a privacy-sensitive system. Practitioners should extend NHI governance to identity verification stacks, especially where backend access reaches personal data.

GDPR pressure will keep shifting from theory to evidence. The regulatory direction of travel is toward documented processing, retention discipline, and auditable accountability, not broad assurances that an app is secure. That puts control mapping and evidence collection at the centre of digital identity programmes. Practitioners should expect privacy scrutiny to intensify around digital ID and verification workflows.

Digital identity teams need a named control owner for processing risk. When an authority examines an identity app, ambiguity over who owns data handling, notice quality, and retention enforcement becomes a liability. The organisation needs one accountable control owner across privacy, IAM, and application operations. Practitioners should assign ownership before the next regulator asks for it.

What this signals

Verification governance is becoming a board-level evidence problem. Digital identity programmes will be judged less on the elegance of the user journey and more on whether they can prove minimised collection, controlled retention, and accountable processing. For practitioners, that means privacy evidence must be built into operating rhythm, not assembled after the regulator asks.

The control surface now includes backend NHIs that support identity verification, which means privacy risk and machine identity risk are converging in the same stack. If service accounts, API keys, or certificates remain poorly governed, they can weaken both security and compliance. Practitioners should fold verification platforms into their NHI inventory and review cycle.

GDPR scrutiny will reward control clarity over vendor assurances. Teams that can show ownership, lawful basis, and deletion enforcement will be better placed than teams relying on high-level statements of security. This is especially true where identity verification data flows through multiple systems, because regulator questions will follow the chain of processing rather than the marketing boundary.

For practitioners

• Map the full personal-data lifecycle Document what the digital ID app collects, why it collects it, where it is stored, who can access it, and when it is deleted. Keep the map aligned to lawful basis and purpose limitation so it can be shown to regulators on request.
• Separate security evidence from privacy evidence Maintain one control set for access control, logging, and hardening, and a second set for notices, retention, consent or lawful basis, and minimisation. Reconcile both in a single governance register so gaps are visible before an audit.
• Inventory backend NHIs supporting the identity stack List every service account, API key, certificate, and integration used by the digital identity platform, then assign owners and rotation rules. This reduces the chance that hidden machine access undermines the platform’s compliance posture.
• Prepare regulator-ready accountability records Keep evidence for data-protection decisions, DPIAs where applicable, access reviews, and processor oversight in one place. If the app handles identity verification data, the organisation should be able to show who approved each control and why.

Key takeaways

• The sanction shows that digital identity governance is a privacy and accountability issue, not just a technical security issue.
• Identity verification platforms need evidence for lawful basis, retention, access control, and processor oversight, not just a secure user experience.
• Backend NHIs inside identity stacks must be governed with the same lifecycle discipline as user access because they shape the real exposure surface.

Key terms

• Digital Identity: Digital identity is the set of attributes, credentials, and access relationships used to authenticate and authorize a person, service, workload, or automated system. In security operations, it becomes the control layer that determines what can act, where it can go, and how far compromise can spread.
• Lawful Basis: The legal reason an organisation is allowed to collect and process personal data under GDPR. In practice, it must be specific, documented, and matched to the actual processing activity. If access or use drifts beyond that purpose, the compliance position weakens quickly.
• Non-Human Identity (NHI): A digital identity assigned to a non-human entity such as a software application, service account, API key, bot, machine, or AI agent that enables it to authenticate and interact with systems without direct human involvement. NHIs now outnumber human identities in most enterprises by 25 to 50 times.

What's in the full analysis

Yoti's full article covers the operational detail this post intentionally leaves for the source:

• The company’s framing of the AEPD sanction and its appeal posture.
• The specific data-protection issues Yoti says relate to the Digital ID app.
• The company’s statement that the findings do not apply to all users or clients.
• The Spanish-language access note and original source wording.

👉 Yoti's full post covers the company’s response, appeal position, and the scope of the regulator’s findings.

Deepen your knowledge

The NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, machine identity security, and secrets management. It helps identity and security practitioners connect access control, lifecycle discipline, and operational accountability across modern programmes.