---

title: DPP QR code modes description: Understand the three QR resolution modes (device-tracked, always-latest, and frozen) and which to use for your product type.

DPP QR code modes

Overview

When a customer or regulator scans a QR code on your product, CRA Evidence needs to know which DPP page to show them. The answer depends on what the QR is attached to: a specific physical device unit, a product box, or a compliance archive.

CRA Evidence supports three modes. You configure this once per product in [Product Settings > DPP > QR Behaviour].

---

The three modes

Device-Tracked (recommended for hardware)

Each physical device unit gets its own unique QR code. When that device's firmware is updated, the QR automatically resolves to the new version's DPP.

How it works:

1. You create the new firmware version (for example v1.2) in CRA Evidence with its SBOM, VEX statements, and compliance documents, before deploying it to any device.
2. Your OTA system deploys v1.2 to a device.
3. Your OTA system calls the CRA Evidence API to report the update: PATCH /api/v1/products/{product_id}/devices/{device_identifier}/version Body: { "new_version_id": "<uuid of v1.2>" }
4. The next time the QR on that device is scanned, it shows the v1.2 DPP.

This is one HTTP call added to the post-deploy step of your OTA pipeline. No OTA system? A technician portal, firmware installer script, or support process can call the same endpoint after a manual flash.

Why the CRA requires this for hardware: Article 13(8) of Regulation (EU) 2024/2847 requires manufacturers to handle vulnerabilities for a minimum of 5 years. When a patch is released and installed on a device, the DPP must reflect the patched state. A frozen QR still shows the old version, which is inaccurate after any update. Device-Tracked is the only mode that remains accurate throughout the device lifecycle.

Best for: routers, IoT sensors, industrial controllers, embedded systems, and any hardware the manufacturer supports with firmware or software updates.

---

Always-Latest

One QR code for the whole product line. Automatically resolves to the most recently published DPP version whenever a new version is exported.

How it works: when you publish a new DPP version, CRA Evidence automatically updates the QR resolution behind the scenes. No action needed.

When to use: product boxes, retail packaging, marketing materials, software products. The QR is not tied to any specific physical device unit.

Important: do not use this mode for QRs printed on individual device units. A device on older firmware (for example v1.1) will show the latest version's DPP (for example v1.2), including "no known vulnerabilities", even if that specific device has not been patched. This is a compliance risk under Annex II §2(g) of Regulation (EU) 2024/2847.

---

Version-Specific (Frozen)

The QR permanently resolves to the exact version it was created for.

The DPP content at that URL still updates automatically: when a CVE is added or a VEX statement is published for that version, the page refreshes. "Frozen" means the URL is fixed, not the content.

When to use: compliance archives, conformity assessment submissions, audit trails. This is a secondary record of "what shipped at this version", not the primary QR on a physical device.

Most manufacturers only need this when a compliance team or auditor explicitly asks for an immutable version reference.

---

OTA integration guide

For Device-Tracked mode, your OTA system calls one endpoint after each firmware deployment.

Before you start

1. In Product Settings > API Keys, create a key with the device:write scope.
2. Register each device in CRA Evidence, either one at a time via the API or in bulk via the batch endpoint. You will receive a device_code for each device: this is what goes on the QR label.

Registering a device

POST /api/v1/products/{product_id}/devices
Authorization: Bearer <api_key>
Content-Type: application/json

{
  "initial_version_id": "<uuid of the firmware version the device ships with>",
  "device_serial": "SN-001234",
  "device_metadata": { "hardware_rev": "B1", "region": "EU" }
}

The response includes device_code, a 12-character code to embed in the QR label printed on the device.

Reporting a firmware update

Add this call to your OTA post-deploy step:

PATCH /api/v1/products/{product_id}/devices/{device_code}/version
Authorization: Bearer <api_key>
Content-Type: application/json

{
  "new_version_id": "<uuid of the new firmware version in CRA Evidence>"
}

The next time the QR on that device is scanned, it resolves to the updated DPP. The firmware version must already exist in CRA Evidence with its SBOM and compliance documents before you deploy it to devices.

You can also identify devices by serial number: replace {device_code} with the device's serial.

Finding devices on vulnerable firmware

GET /api/v1/products/{product_id}/devices?affected_by_cve=CVE-2026-99999
Authorization: Bearer <api_key>

Returns all devices currently running any version affected by that CVE. Useful for ENISA incident reporting and targeted patch rollouts.

---

Which mode should I choose?