Back to blogAltID Denmark — First EU Age Verification credential in production

AltID and Denmark: the first EU Age Verification credential in production


From pilot to production, faster than expected

Most discussion of the EU Age Verification Blueprint still treats it as something on the horizon — a pilot, a future rollout, a 2026/2027 milestone. Denmark just made it current.

In June 2026, Denmark launched AltID, its national digital identity app, developed by the Danish Agency for Digital Government (Digitaliseringsstyrelsen). What makes this notable isn't the launch itself — several member states are running pilots — it's that Denmark's credential issuer is already listed on the EU's production Trusted List, not a sandbox or testing environment. That's the difference between "this will work eventually" and "this works today."

This analysis is based on "Om AltID" v1.4 (May 2026), the official technical documentation published by Digitaliseringsstyrelsen.

What AltID actually does

AltID is a national digital identity wallet — Denmark's implementation of the EU Digital Identity Wallet under eIDAS 2.0, though built in phases rather than as a full implementation from day one. At launch, it contains two credentials:

An identity card ("legitimationskort") — contains full name, date of birth, address, and CPR number, and can serve as a photo ID document if the user adds their passport photo via NFC chip scan.

An age proof ("aldersbevis") — the one that matters for DSA Article 28. It confirms whether the user is above or below specific age thresholds, without sharing any other personal information.

AltID runs alongside MitID, Denmark's existing national authentication system. Users need MitID to enroll, but once set up, the age proof can be used without re-authenticating via MitID for each use.

The app is available to anyone over 13 with a MitID account and a Danish CPR number. It is voluntary and free.

The nine age thresholds

AltID's age proof doesn't just verify age_over_18. It contains nine distinct boolean attributes: age_over_13, age_over_15, age_over_16, age_over_18, age_over_21, age_over_23, age_over_25, age_over_27, and age_over_67. All are pre-computed at issuance from the user's date of birth in the CPR register.

For an 18-year-old, the credential contains:

  • age_over_13 = true
  • age_over_15 = true
  • age_over_16 = true
  • age_over_18 = true
  • age_over_21 = false ...and so on.

The verifier requests only the specific threshold it needs. The user's device discloses only that attribute — not the others. A platform verifying age_over_18 never learns whether the user is also age_over_21 or age_over_67.

This multi-threshold design is significant: it confirms that the single-threshold assumption common in early integrations is a simplification, not a constraint of the standard. The same infrastructure supports all age restriction scenarios — social networks at 13+, alcohol at 18+, gambling at 21+ — without requiring separate credentials or separate infrastructure.

How the privacy guarantee actually works

The privacy model of AltID is worth understanding in detail, because press coverage of it is frequently imprecise.

What doesn't happen: the issuer (Digitaliseringsstyrelsen) does not receive any notification when a user presents their credential to a platform. As the official documentation puts it: "the issuer cannot know that the credential is being used, nor where." There is no connection between issuers and recipients of credentials.

What the verifier receives: a boolean — is the user over the requested age threshold? Yes or no. Not the exact age, not the date of birth, not the CPR number, not any other personal data.

The unlinkability mechanism: press coverage often describes AltID as using "zero-knowledge proofs." This needs clarification. The official documentation is explicit: ZKP generation and presentation is not supported at launch. The expected incorporation of ZKP technology in future versions of AltID will happen "when the method has been decided in the context of the European Commission's work on technical specifications in this area."

What AltID uses instead is a single-use credential design: when the age proof is issued, 30 unique credentials are generated with the same attributes but different metadata. Each presentation uses one credential from the batch — a different one each time. When the 30 are exhausted, a new batch is generated automatically. Since two verifiers never see the same credential, correlation across sessions is impossible.

This is equivalent privacy in practice — it satisfies the same unlinkability requirement — through a different cryptographic mechanism than ZKP. Both approaches are valid under the AV Blueprint specification.

How the protocols work

AltID supports two electronic presentation methods:

OID4VP — the recommended protocol. The user scans a QR code shown by the verifier (cross-device), or follows a deep link if they're on the same device. The verifier receives the credential over the internet. This is the protocol prescribed by the European Commission for online credential sharing, and it's the method that enables interoperability with verifiers across the EU.

Signed QR codes — a protocol developed specifically for AltID for offline, in-person scenarios (festivals, venues without connectivity). The QR contains the credential data directly and can be scanned without an internet connection. This is an addition to the EU framework, not part of the standard AV Blueprint.

One important detail for integrators: AltID does not support DC API (Digital Credentials API) at launch. The browser-native flow using ISO 18013-7 Annex C ("org-iso-mdoc") is part of the evolution path for the EU AV ecosystem but is not present in this first version of AltID. Platforms integrating with OID4VP today will be compatible with AltID from day one.

The Trusted List status — why it matters technically

For a platform implementing age verification, the Trusted List is the mechanism that makes a credential verifiable in the first place. A relying party's verifier checks the issuer's certificate against that list before accepting any presentation as valid.

Denmark's credential issuer being on the production list means a platform with real users in Denmark can verify real proof-of-age attestations today, against the official EU trust framework. This is not testing infrastructure — it is live.

Recipient registration — a detail that matters

One aspect that distinguishes AltID from a pure AV Blueprint implementation: verifiers that want to request the identity card must register in AltID's recipient registry. Registration requires a Danish OCES system certificate and login via MitID Erhverv (the business authentication system).

For the age proof specifically, registration is not required — any verifier can request age_over_X attributes without prior registration. This is consistent with the AV Blueprint's design, which deliberately avoids requiring Relying Party registration for age verification.

What this means for platforms

If your platform serves Danish users — or EU users who hold an AltID credential — there is no longer a credible argument that verification infrastructure "isn't ready yet." It is live, in production, issuing real credentials to anyone over 13 with a Danish CPR number and MitID.

The OID4VP integration path is standard and works with any compliant verifier. A platform using an AV verification service that correctly implements the EU AV Blueprint can accept AltID credentials without any Denmark-specific integration work.

The platforms that integrate now, while this is still a relatively small early-adopter market, will have working infrastructure and real operational experience by the time enforcement attention broadens beyond the largest platforms — which, based on the Meta and Snapchat proceedings opened in 2026, appears to be a question of when, not if.


Technical details in this article are based on "Om AltID" v1.4 (29 May 2026), published by Digitaliseringsstyrelsen, Denmark's Agency for Digital Government.

Sources for this article are linked inline. For the full list of primary sources espuni relies on, see references.