Fictitious example. ACME Embedded GmbH, its products, records and document IDs are invented for illustration. Use this as a structural model, not as a template to adopt unchanged — and not as legal advice.
SDL-STD-034 — Default Credential Policy
| Document ID | SDL-STD-034, rev. 1.0 |
| Owner | Product Security Lead |
| Approved by | Managing Director, 2026-07-28 |
| Reference | CRA Annex I I(2)(c); verified per release via SDL-CHK-030 section B |
| Applies to | All ACME products with any authenticated access (device, companion app, web UI, maintenance interfaces) — applied to SensorNode S300 in §4 |
1. Policy statement
No ACME product ships with a universal default password, default key, or default PIN of any kind. Every unit must either
(a) carry a per-device unique credential, generated during production, printed only on the device label / commissioning document and stored nowhere else in plaintext, or
(b) enforce a mandatory first-use credential setup: the product is functionally locked until the user sets a unique credential; the setup flow cannot be skipped, and the pre-setup state exposes no other functionality.
Hard prohibitions: shared credentials across units or product lines; hidden/undocumented maintenance accounts; vendor "backdoor" recovery passwords; credentials derivable from public identifiers (MAC, serial) by a static algorithm.
2. Requirements common to both options
- Generation: credentials/keys generated with a TRNG (device or production system); minimum entropy 64 bits for machine credentials, and for human-entered passwords a minimum length of 10 characters with a deny-list check.
- Storage: on-device only as salted hash (human passwords) or in hardware key storage (machine credentials); production systems retain no plaintext copy after label printing.
- Reset path: factory reset requires physical presence (button sequence) and wipes user data and credentials, returning the device to state (a)/(b) — never to a universal default.
- Rate limiting: authentication attempts limited (exponential backoff) by default.
- Documentation: the user manual describes credential setup and reset; the technical documentation describes the mechanism and entropy source (Annex VII evidence).
3. Production and logistics implications (why this is pre-development)
Option (a) requires the end-of-line test station to generate, inject, and label per-device credentials — a production-line capability that must be planned with manufacturing before the line is designed. Option (b) requires the locked first-use state to be part of the application architecture from the start. Choosing late means retrofitting either the factory or the firmware.
4. Application to SensorNode S300
The S300 has no human login on the device itself; its "credentials" are machine identities:
| Access | Mechanism | Option applied |
|---|---|---|
| Mesh join (device ↔ gateway) | Per-device identity key pair, generated at end-of-line in MCU key vault; public key registered to production database; join authorised via gateway allow-list | (a) per-device unique, hardware-held |
| Commissioning (installer via gateway UI) | Commissioning of a node requires the per-device pairing code printed on the S300 label + physical join-button press on the node | (a) printed per-device code |
| UART maintenance protocol | Challenge–response against per-device maintenance key (derived in key vault, never exported) | (a) hardware-held |
| Gateway G50 web UI (context) | Mandatory admin password setup on first boot; device locked otherwise | (b) first-use setup (already shipped, FW 1.0) |
Explicit statement for the release gate: the S300 contains no password, PIN, or shared secret common to more than one unit; checklist items B1–B4 of SDL-CHK-030 verify this on a production-fused sample.
5. Records
End-of-line credential generation logs (hashes/serials only), label print records, and the entropy-source qualification report are quality records referenced by the technical documentation.