How it is created — SDL-STD-034 Default Credential Policy

1. Why this is a pre-development artifact

Both compliant options cost money in places that are hard to change later. Per-device credentials require the end-of-line test station to generate, inject and print them — a production-line capability. Forced first-use setup requires a locked pre-setup state in the application architecture. Decide after the line is built or the firmware is written and you pay twice.

2. Inputs

• The list of every authenticated access path in the product family: device interfaces, maintenance protocols, companion app, web UI, cloud pairing. Take it from the attack-surface inventory, not from memory.
• Your production capability: does the end-of-line station have a TRNG, a label printer, and a database?
• The threat model's findings on device theft and cloning.

3. Steps

1. State the prohibition first, in one sentence, with no exceptions: no universal default password, key or PIN. Then name the two permitted options — per-device unique credential, or mandatory first-use setup.
2. Close the loopholes explicitly. Shared credentials across a product line, hidden maintenance accounts, vendor recovery passwords, and credentials derived from a public identifier by a static algorithm are all "defaults" in practice. If they are not named, they will appear.
3. Fix the parameters that engineering will otherwise invent: entropy source and minimum entropy for machine credentials, minimum length and deny-list for human passwords, storage form (salted hash or hardware key store), rate limiting on by default.
4. Define the reset path. Factory reset must require physical presence and must return the device to the per-device or locked state — never to a shared default. This is where many otherwise-clean designs fail.
5. Walk each access path in the product and pick an option per path. This is the application table; it is what the release gate checks. Machine identities and human logins usually land on different options.
6. Hand the consequences to the right teams now: production engineering gets the generation, injection and labelling requirement; firmware gets the locked first-use state; documentation gets the setup and reset instructions for the manual and the technical documentation.

4. Done when

• Every authenticated access path in the product appears in the application table with an assigned option.
• The technical documentation can state the mechanism and its entropy source as evidence.
• The release checklist has items that verify this on a production-fused sample, not on a development build.
• Production records (generation logs with serials and hashes only, label print records) are defined as quality records.

5. Common mistakes

Assuming a "device without a login" has no credentials — machine identities, pairing codes and maintenance keys are credentials. Storing the plaintext of per-device credentials in the production database after the label is printed. Documenting the policy but verifying it on an engineering sample where the fuses are open.

6. In TRA Studio

The credential requirements land as security requirements on the product and as an activity in the Secure Lifecycle. Assign the Annex I I(2)(c) requirement to that activity so the coverage view records who owns it and where the evidence comes from.