Safeguards Before Framework: The Missing Sequence in Digital Identity
- Ott Sarv
- Apr 30
- 11 min read
Safeguards are necessary.
They are also not enough.
That is the uncomfortable starting point for the next phase of the digital identity debate. Around the world, Digital Public Infrastructure is being promoted as a way to improve inclusion, service delivery, payments, data exchange, identity, and state capability. The language is attractive because it offers a positive frame. Infrastructure sounds neutral.
Public sounds legitimate. Digital sounds modern. But identity is not neutral infrastructure.
Identity is where the state, the person, the market, and the administrative record meet. It can enable access to services, rights, mobility, finance, education, employment, and participation. It can also enable exclusion, surveillance, coercion, profiling, dependency, and administrative harm.
That is why safeguards matter.
The Universal DPI Safeguards Framework, released through a multistakeholder process under the stewardship of the Office of the Secretary-General’s Envoy on Technology and UNDP, was created to guide safe and inclusive Digital Public Infrastructure. UNDP describes it as a set of actionable guidelines intended to ensure that DPI serves the public interest.
That is a useful intervention. But a safeguard is not a trust framework.
A safeguard can identify the harm to avoid. It can ask whether the system is inclusive, safe, accountable, proportionate, resilient, and rights-respecting. It can expose weak assumptions before a country scales a digital identity system. It can help donors, governments, civil society, and implementers ask better questions.
But it does not itself create legal authority.
It does not...
... establish an authentic source.
... authorise an issuer.
... register a relying party.
... define the legal effect of a qualified electronic signature or qualified electronic seal.
... create validation mechanisms.
... not allocate liability.
... supervise trust service providers.
... correct the record when the state is wrong.
That is why the sequence matters:
Start with safeguards.
Convert the risks into legal and institutional requirements.
End with a framework that can actually be relied upon.
Safeguards are the entry point
Safeguards should come first because they force a basic question that technology programmes often avoid:
Should this system exist in this form, in this context, for this purpose, with these institutions, and with these consequences?
That question is not anti-technology. It is governance. A country may have a persuasive identity roadmap and still be unprepared to deploy the system safely. It may have weak civil registration. It may lack independent supervision. It may have no practical remedy for people who are wrongly excluded. It may depend on a donor-funded platform with no long-term fiscal model. It may have procurement rules that favour lock-in. It may have no alternative access channel for people without devices, connectivity, literacy, documentation, or trust in the state.
Safeguards are valuable because they make those conditions visible.
They are especially important where Digital Public Infrastructure is presented as a ready-made good. DPI language can move quickly from policy aspiration to procurement object. A system becomes a stack. A stack becomes a programme. A programme becomes a donor-funded implementation. The risk is that social, legal, institutional, and fiscal questions are treated as later details.
They are not later details.
They are the conditions of legitimacy.
UNDP’s work on governing digital legal ID systems recognises this. It states that digital legal ID can support transformation and development, but that effective implementation requires robust governance to ensure inclusion, safety, and preservation of rights. It also links legal identity to civil registration and to the wider legal identity management ecosystem.
That point matters because it moves identity away from the product layer.
Digital legal identity is not a wallet interface. It is not a QR code. It is not a reusable component. It is the combination of law, records, institutions, technology, rights, and remedy that makes identity usable and contestable.
A safeguard framework helps ask whether those conditions are present.
It does not create them.
Safeguards can become theatre
Safeguards can also be misused.
A country can adopt safeguards language and still deploy an unsafe system. A donor can require safeguards language and still fund only the visible platform. A vendor can claim alignment with safeguards and still avoid the hard parts of correction, supervision, lifecycle funding, and relying party discipline.
This is the danger of safeguards as theatre.
The language is present. The system is still weak.
The risk is not hypothetical. Digital identity programmes often become most polished at the surface. They show enrolment. They show authentication. They show a wallet. They show an electronic attestation of attributes (credential). They show a dashboard. They show a successful transaction.
They do not always show:
the person who cannot correct a record;
the relying party that asks for too much;
the person without a device;
the appeal that takes months;
the issuer that loses competence;
the operational cost after the pilot ends.
A safeguards checklist may catch some of this. But only if it is treated as a hard gate, not as a narrative accessory.
If safeguards are used merely to make a programme appear responsible, they become part of the problem. They add legitimacy without changing power.
That is why safeguards must lead to binding design choices.
A safeguard that identifies ...
exclusion must lead to alternative access, assisted channels, correction rights, and non-discrimination duties.
surveillance risk must lead to purpose limitation, relying party registration, data minimisation, logging, supervisory authority, and sanctions.
weak institutional capacity must lead to phased deployment, capability-building, procurement reform, and realistic operating budgets.
political misuse must lead to legal limits, independent oversight, transparency, and remedy.
If the safeguard does not change the system, it is not a safeguard. It is a paragraph.
Framework is the destination
A trust framework does something different from a safeguard framework.
It turns public-interest limits into enforceable architecture.
It answers:
who is allowed to do what;
under which authority;
in which format;
with which evidence;
under which supervision;
with what consequence when something goes wrong.
That is why an eIDAS-style framework is not simply more detailed guidance. It is a different kind of instrument.
Regulation (EU) 2024/1183 defines the European Digital Identity Wallet as an electronic identification means that allows users to securely store, manage, and validate person identification data and electronic attestations of attributes for presentation to relying parties, and to sign or seal by means of qualified electronic signatures or qualified electronic seals.
The same Regulation defines an authentic source as a repository or system recognised under Union or national law as a primary source of attributes. It defines validation as the process of verifying and confirming that data in electronic form are valid under the Regulation.
Those definitions are not cosmetic.
They begin to assign roles.
Regulation (EU) 2024/1183 also requires common protocols and interfaces for issuance, relying party requests, validation, presentation, wallet-to-wallet interaction, relying party authentication, verification of wallet authenticity and validity, erasure requests, suspicious request reporting, and the creation of qualified electronic signatures or qualified electronic seals. It requires relying parties to register, identify themselves to users, state intended use, and avoid requesting data beyond what they registered.
That is framework logic.
It does not simply say be safe.
It defines what safe reliance requires.
Safeguards and frameworks answer different questions
The mistake is to ask whether safeguards or a legal trust framework are better.
They do different work.
Question | Safeguards | Trust framework |
Core purpose | Ask whether the system should be deployed and under what limits | Define how the system can be relied upon |
Primary concern | Inclusion, safety, proportionality, accountability, misuse, sustainability | Legal authority, roles, formats, validation, relying party duties, legal effect, remedy |
Main value | Exposes risk before harm scales | Converts trust into enforceable obligations |
Main weakness | Can remain non-binding if not converted into law or contracts | Can become lawful machinery that still excludes or harms if safeguards are ignored |
Correct role | Entry point | Destination |
A country that has safeguards but no framework may have good principles and weak enforceability. A country that has a framework but ignores safeguards may have legal machinery and still produce exclusion, coercion, or political misuse.
The correct sequence is not safeguards instead of framework.
It is safeguards before framework.
Safeguards identify the risks. Framework converts the response into law, institutions, formats, procedures, supervision, and remedy.
That is the same discipline behind the Seven Layers argument on law before the code: a digital act does not gain public meaning because an interface exists. It gains public meaning because legal authority, institutional mandate, evidence, and remedy sit behind it.
Why this matters for the EUDI Wallet debate
This distinction is important because the EUDI Wallet is sometimes pulled into two opposite narratives.
One narrative says: if a country adopts an eIDAS-style framework, it does not need DPI safeguards.
That is too strong.
Another says: DPI safeguards are the essential governance answer for identity systems.
That is also too strong.
The more accurate view is that an eIDAS-style framework internalises many safeguards that DPI guidance may otherwise need to add externally. It can define relying party governance, validation mechanisms, certification, data protection duties, qualified trust services, authentic sources, electronic attestations of attributes (credentials), person identification data, supervision, and legal effect.
But it does not automatically answer every public-interest risk.
A country may adopt impressive wallet legislation and still exclude people who lack birth registration, devices, connectivity, stable residence, literacy, accessibility support, or trust in government systems. It may define relying party obligations but lack the supervisory capacity to enforce them. It may require validation mechanisms but have poor authentic sources. It may mandate certification but lack competent conformity assessment capacity. It may create a wallet and still have no realistic funding for recovery, correction, helpdesks, audits, cybersecurity, and long-term maintenance.
That is why safeguards remain useful. Not as a substitute for the framework. As a stress test around it.
This also connects to the earlier Seven Layers article on why the EUDI Wallet is not foundational identity. Replace this placeholder with the final Article 1 URL after publication. The wallet may carry person identification data and electronic attestations of attributes (credentials), but it depends on the legal and institutional foundations below it. A safeguard can expose whether those foundations are weak. A framework must then define how trust can operate despite that risk, or prevent deployment until the risk is resolved.
The implementation trap
The most dangerous reform path is to skip both stages.
That happens when a country adopts the language of safeguards and the language of wallets but builds neither a credible public-interest gate nor a binding trust framework.
The result looks modern. It may even be celebrated.
There is a policy document. There is an inclusion narrative. There is a platform. There is a pilot. There are use cases. There are workshops. There is a roadmap. There may even be a trust mark.
But when something goes wrong, the system has no teeth.
The person cannot correct the source record. The relying party cannot be sanctioned. The issuer cannot be suspended. The validation mechanism is incomplete. The alternative access route is not funded. The grievance mechanism is slow or symbolic. The supervisory body lacks mandate or capacity. The donor has moved on. The vendor owns the operational knowledge. The state inherits the liability.
That is not safe DPI.
That is digitised fragility.
The Seven Layers article on the Friday Test offers a practical way to expose this. If a legal change happens on Friday, the operational ecosystem should reflect it by Saturday and remain inspectable by Monday. A safeguard may ask whether the system can avoid harm. The framework must answer how the change is actually reflected, validated, logged, supervised, and corrected.
What a serious country should do
A serious country should begin with a safeguards assessment before procurement. Not after procurement. Not after piloting. Not after the political announcement.
Whether the identity system is necessary, proportionate, inclusive, fundable, governable, and capable of remedy.
Which legal and institutional gaps must be closed before scaling.
Should be how those safeguards will become enforceable.
This is where the framework begins.
The country should define the legal authority for identity and attributes. It should identify authentic sources. It should determine which institutions may issue person identification data and electronic attestations of attributes (credentials). It should govern relying parties before they begin requesting wallet data. It should create validation mechanisms before encouraging reliance. It should define the legal effect of electronic identification, qualified electronic signatures, qualified electronic seals, and attribute presentation. It should provide correction, suspension, revocation, appeal, incident handling, and remedy. It should fund the lifecycle.
The point is not to copy Europe.
The point is to build the minimum conditions for safe reliance.
This is also where the Seven Layers distinction between Digital Public Infrastructure, Digital Public Goods, Digital Public Functions, and Digital Public Services becomes operational. A reusable component is not the same thing as a public function. Infrastructure is not the same thing as lawful decision-making. A wallet is not the same thing as legal identity. A safeguard is not the same thing as a framework.
The same logic appears in Seven Layers work on data exchange governance: the fact that a system can exchange data does not mean an institution is entitled to request, receive, or rely on that data.
What donors should fund differently
This also changes the donor conversation.
Donors often prefer visible outputs. They can fund enrolment, platforms, wallets, pilots, toolkits, registries, dashboards, and use cases. Those outputs are easier to announce and easier to measure.
But the costs that make identity trustworthy are less visible:
correction;
helpdesks;
appeals;
accessibility;
supervision;
audits;
cybersecurity;
relying party monitoring;
lifecycle updates;
recovery;
certification;
public communication;
institutional capacity;
long-term maintenance.
If donors fund the visible layer and leave the operating layer unfunded, they have not funded identity.They have funded exposure.
That does not mean donors should withdraw. It means they should fund the boring parts that make safeguards real and frameworks operational.
DIAL has made a similar point in its work on funding good DPI, arguing that funding must cover the non-technology elements of DPI, including coordination, planning, citizen engagement, safeguards, and redress mechanisms. It also warns that many ecosystem functions need long-term funding rather than one-off deployment finance.
That point should be taken seriously in digital identity.
A donor-funded identity programme should be judged not only by how many people are enrolled or how many transactions occur. It should be judged by whether people can correct errors, whether alternative access exists, whether relying parties are disciplined, whether validation works, whether the system survives after external funding, and whether a person harmed by the system can get a meaningful remedy.
That is the difference between digital inclusion and digital dependency.
Why this matters for regional conventions
Safeguards before framework also matters for regional instruments.
Africa, for example, does not need a copy of the European Digital Identity Framework. It needs a regional answer to its own trust problems: legal identity, cross-border movement, business representation, public documents, professional qualifications, official notifications, payments, data protection, cybersecurity, and administrative cooperation.
A future amendment or complementary instrument linked to the Malabo Convention should begin with safeguards because the regional context matters. Exclusion, state capacity, civil registration gaps, vendor dependency, cross-border migration, informal economies, and institutional trust cannot be treated as European implementation details.
But it cannot end with safeguards.
If the region wants wallet interoperability, it will need a framework. That framework must define competent issuers, authentic sources, electronic attestations of attributes (credentials), relying party governance, validation, legal effect, supervision, liability, and remedy.
The same logic applies elsewhere.
India may not copy Europe, but it may need interoperability controls for business, education, professional mobility, services trade, and regulated-sector trust. ASEAN, the Gulf, Latin America, and other regional spaces may each find different institutional routes. The form can differ. The functions cannot disappear.
Safeguards identify what must be protected.
Framework defines how trust can operate.
The final test is remedy
Every digital identity debate eventually comes back to remedy.
When the system is wrong, who can correct it?
When the relying party overreaches, who can stop it?
When the issuer fails, who can suspend it?
When the wallet is compromised, who can recover it?
When a person is excluded, who must provide an alternative?
When a public body relies on stale data, who bears responsibility?
When a donor-funded system becomes unaffordable, who pays to keep people protected?
This is where rhetoric ends.
A system without remedy is not trustworthy.
It may be efficient. It may be innovative. It may be inclusive in a dashboard. It may be interoperable in a pilot. But it is not trustworthy if the person harmed by it cannot change the outcome.
That is why safeguards and frameworks must be connected.
Safeguards without remedy are aspirations. Framework without remedy is machinery. Trust requires both.
Start with safeguards, end with framework
The right sequence is not complicated.
Start with safeguards because identity systems can harm people at scale.
Use safeguards to test necessity, proportionality, inclusion, accountability, public interest, institutional capacity, procurement risk, fiscal sustainability, and misuse.
Then build the framework.
Define legal authority. Recognise authentic sources. Authorise issuers. Govern relying parties. Require validation. Set formats and baselines. Certify what must be certified. Supervise the ecosystem. Provide correction, suspension, revocation, incident handling, appeal, and remedy. Fund the lifecycle.
That is the sequence.
Safeguards tell us what must not go wrong.
Frameworks define what must happen so that it does not.
A country that stops at safeguards has principles without enforceability.
A country that jumps to framework without safeguards risks building lawful machinery that still excludes, coerces, or harms.
The answer is not safeguards or framework.
The answer is safeguards before framework.
That is how digital identity moves from aspiration to accountable trust.
