Germany's EUDI Wallet Just Landed on GitHub: A Developer's First Look at the Reference Implementation

On 17 August 2026, three new repositories appeared under a GitHub organization called german-national-wallet: de-eudi-wallet-ios, de-eudi-wallet-android, and de-eudi-wallet-backend. They are exactly what the name suggests — the source of Germany's official national implementation of the European Digital Identity Wallet, mirrored out of the government's internal repository and onto the public internet. Commits keep landing (the backend repo shows an "OSS sync" commit as recently as 31 August; the linked issue trackers were still active as of 3 September), and two related bug-bounty-adjacent repos (issues-tracker-ios, issues-tracker-android) sit alongside them for public findings.

This isn't a hobby project or a hackathon fork. It sits under the german-national-wallet org, it's licensed EUPL-1.2 (the iOS and Android apps) and Apache-2.0 (backend and supporting libraries), and the backend README points back to architecture documentation hosted on the government's own opencode.de code forge. Per Germany's own digital-identity program page, the project sits under the Bundesministerium für Digitales und Staatsmodernisierung (BMDS), with the Bundesagentur für Sprunginnovation (SPRIND) leading the interdisciplinary build team — worth being precise about, since the opencode.de URL path (bmi.usercontent...) could easily be misread as attributing this to the Interior Ministry (BMI) instead.

If you're building anything that will need to accept or verify a German EUDI Wallet credential, this is the first time you can read the actual client code instead of inferring behavior from specs. Here's what's actually in the repos, what's conspicuously missing, and why both matter.

Why this had to be open source in the first place

This isn't a voluntary transparency gesture — it's a legal requirement. Regulation (EU) 2024/1183, which amended the original eIDAS Regulation, inserted a new Article 5a establishing the European Digital Identity Wallet framework. Two provisions of Article 5a are directly relevant here:

• Article 5a(1): each Member State shall provide at least one European Digital Identity Wallet within 24 months of the date of entry into force of the implementing acts referenced later in the article — which resolves to a hard deadline of 24 December 2026.
• Article 5a(3): "The source code of the application software components of European Digital Identity Wallets shall be open-source licensed."

That second clause is why these repos exist at all, and it's also why they look the way they do: the law requires the application software components to be open source, not the entire delivery pipeline. That distinction shows up immediately once you look at what's published.

What's actually in the repos

de-eudi-wallet-backend is the most substantial of the three. It ships five components, each its own Spring Boot entry point that can also run combined:

The README is explicit that the wallet mobile app is the only authenticated client of this backend, and that the status-list read surface is intentionally public. A SECURITY.md in the repo points to a bug bounty program for security findings.

de-eudi-wallet-ios and de-eudi-wallet-android are the client applications. Both READMEs open with the same sentence: "This repository is one-way, read-only and flows out of an internal repository." That's the operative fact for anyone hoping to send a pull request — you can file issues on the separate issues-tracker-ios/issues-tracker-android repos, but you're reading a mirror, not contributing to a living branch.

What's deliberately stripped out — and why it matters more than what's included

The two client READMEs are unusually specific about what's not there, which is itself useful signal for anyone assessing what "open source" means in this context:

• Real configuration values are gone. Per-environment settings under Wallet/Config/ (iOS) carry PLACEHOLDER_* values instead of real keys — you can see what settings exist without learning where they point. GoogleService-Info.plist is omitted entirely on iOS; the Android README says service endpoints, tokens, and the class that holds them are simply absent, "and there are no placeholder values to mistake for real ones."
• CI/CD and signing tooling are absent. No GitHub Actions workflows, no fastlane, no Xcode Cloud scripts on iOS; no Gradle build files or convention plugins on Android.
• Tests are absent on both platforms — test targets, test plans, and the mocking harness are not published.
• A commercial typeface is swapped out. The iOS app normally uses Diatype, which the team can't redistribute; the published repo ships Roboto (Apache-2.0) in its place.
• Both READMEs state plainly: "This is not a reproducible build." What you clone will not correspond byte-for-byte to what ships on the App Store or Play Store.

None of this is unusual for a government open-sourcing a security-sensitive production app under legal deadline pressure — but it does mean "open source" here means auditable application logic, not build-your-own-wallet-from-scratch. If your integration plan assumed you could compile and run this yourself as a reference client for testing, budget time to build your own harness around the exposed logic instead.

The gap nobody's advertising: Germany's own timeline vs. the Article 5a deadline

Here's the detail that's easy to miss if you only read the GitHub activity: Germany's own program page states the first stage of the state EUDI Wallet is planned for launch in early 2027 — after the 24 December 2026 deadline set by Article 5a(1). A sandbox testing environment supporting PID (Person Identification Data) and EAA (Electronic Attestations of Attributes) credential types opened during 2026, and private wallet providers become eligible for certification roughly 12 months after the state wallet's own launch.

That doesn't necessarily put Germany in breach — Article 5a's Member State obligation can in principle be met through the sandbox/rollout sequencing, and enforcement mechanics for a slipped launch date are not the same as a hard legal violation with an immediate penalty. But if your product roadmap assumed "every EU citizen has a working EUDI Wallet by January 2027," Germany's own stated plan says otherwise for at least the early part of that window. Build your relying-party integration against the sandbox and this reference client now; don't schedule a hard go-live date against the assumption that the German wallet is fully live the day after the EU deadline passes.

What to actually do with this if you're building a relying-party integration

1. Read the backend component boundaries before you design your integration. The WPB/RWSCA/MDVM/PNS split tells you which concerns the wallet provider keeps server-side (attestations, remote signing, device integrity) versus which live entirely on-device — useful when you're deciding what your own verifier needs to check locally versus what it can trust from a signed attestation.
2. Use the status-list endpoint pattern as your model for credential revocation checks. The backend explicitly documents its Token Status List surface as public and unauthenticated, consumed by the PID Provider — that's the shape of contract you should expect from any conformant EUDI Wallet issuer, not just Germany's.
3. Don't build your test harness assuming a reproducible build. Since tests, CI, and real endpoints are stripped, treat this repo as a reference for protocol and data-flow behavior, and pair it with the OpenID4VP and SD-JWT implementation guides for the actual wire protocol your relying-party code needs to speak.
4. Track the issues-tracker-ios/issues-tracker-android repos, not the app repos, for signal. Since the app repos are one-way mirrors, real-time developer feedback and bug reports will surface there first.
5. If you're deploying the relying-party side of this in the EU, keep the hosting jurisdiction question separate from the protocol question. Accepting a German EUDI Wallet credential is a protocol-compliance problem; where you host the verifier that processes the resulting PID data is a completely separate GDPR/data-residency decision. Our eIDAS 2.0 relying-party developer guide covers the latter in depth.

The bigger pattern

Article 5a(3)'s open-source mandate means every Member State standing up its own wallet under this deadline will eventually have to publish something similar. Germany is simply first out of the gate with a working repo you can actually read three months before the legal deadline — not a spec document, not a slide deck, but the Spring Boot services and mobile client code a citizen's phone will actually run. Whatever your relying-party stack looks like, this is the closest thing to ground truth currently available for how a real national wallet implementation is structured, and it's worth the hour it takes to read through the five backend components and both mobile READMEs before you finalize your own integration architecture.

Sources: Regulation (EU) 2024/1183, Article 5a (eIDAS amending regulation) · german-national-wallet GitHub organization · Germany's official EUDI Wallet program page (BMDS) · BMI opencode.de architecture documentation forge