How the Corona-Warn-App works

On 16 June 2020 Germany released the Corona-Warn-App, its official COVID-19 contact-tracing app. Within 24 hours it had been downloaded millions of times, making it one of the fastest-adopted government apps in European history.

As a software company with a foot in the German market, we followed the development closely — partly out of professional curiosity and partly because it is a case study in how to ship a privacy-sensitive app under enormous public scrutiny. Here is what the app does, how it works under the hood, and why the architecture decisions matter.

What the Corona-Warn-App does

The purpose is simple: if you spent a relevant amount of time near someone who later tests positive for SARS-CoV-2, the app warns you so you can get tested and isolate before you unknowingly infect others.

The hard part is doing that without building a central database of who met whom.

The architecture: decentralised by design

Germany initially considered a centralised model, where encounter data would be uploaded to a government server. After a public debate involving privacy researchers, the federal government switched in April 2020 to a decentralised approach based on the Apple and Google Exposure Notification framework. This decision is the single most important thing about the app.

Here is the flow in plain terms:

1. Your phone broadcasts random IDs. Using Bluetooth Low Energy, the app sends out short-lived, randomly generated identifiers that change every few minutes. They contain no personal data.
2. Your phone records the IDs it hears. Nearby phones running the app store each other's random IDs locally, along with signal strength and duration, for 14 days.
3. A positive test is verified. If you test positive, you can share your result in the app. A verification step — a QR code from the lab, or a TAN from a hotline — ensures only genuine results are uploaded.
4. Only your keys leave your phone. The app uploads the keys from which your recent random IDs were derived. No location, no contact list, no name.
5. Everyone's phone checks locally. Each app regularly downloads the list of published keys and matches them against the IDs it recorded. The matching happens on your device, not on a server.
6. Risk is calculated on your device. Using proximity and duration, the app estimates your exposure risk and displays a warning if it crosses a threshold.

The server never learns who met whom. That is the point.

Why open source matters

SAP and Deutsche Telekom built the app on behalf of the federal government, and the full source code — mobile apps, backend, verification server — was published on GitHub before launch.

For a developer this is remarkable. Thousands of people reviewed the code, filed issues and submitted fixes before the public ever installed it. For the public it meant that the privacy claims could be independently verified rather than taken on faith. Adoption of a voluntary app depends on trust, and open source is the most credible way to earn it.

Limitations worth knowing

The app is not a silver bullet.

• Bluetooth is a proxy, not a measurement. Signal strength through a wall or a bag is imprecise, so both false positives and false negatives occur.
• It needs adoption. The benefit grows with the square of the user base; a warning only fires if both people run the app.
• Test results need to be connected. A positive result only helps if the lab or test centre can deliver it into the app with a verified QR code — which requires integration work on the lab side. We expect this to become a significant topic as testing scales up.

What software teams can learn from it

Three lessons we are taking into our own projects:

1. Privacy is an architecture decision, not a policy document. The decentralised model makes misuse technically impossible rather than merely forbidden.
2. Transparency beats marketing. Publishing the code did more for adoption than any campaign could.
3. Integration is where public-health software lives or dies. The app is only as useful as the data pipelines feeding it.

We will revisit that last point. At Daleenda we are already looking at what it takes for testing facilities to plug into this ecosystem — and the answer is that the tooling barely exists yet.