Secrets should have a deliberate lifecycle. Product teams should distinguish user credentials, device identities, API tokens, cryptographic keys and build or signing secrets, then define how each is created, protected, changed and retired. ENISA's secure-by-design guidance specifically supports unique device identities and secrets rather than unnecessary shared credentials.
Secrets and Credentials Affect Several Annex I Outcomes
Secrets and credentials appear throughout product-security architecture even though the CRA does not define one standalone secrets-management control. Annex I requires secure-by-default configuration and protection from unauthorised access through appropriate mechanisms including authentication, identity or access management. Confidentiality and integrity requirements can also depend on cryptographic material and protected credentials. Product teams should therefore treat credential design as part of the cybersecurity risk assessment and product architecture rather than only as an operational concern after release.
- Identify security-sensitive credentials and secrets.
- Connect them to relevant security requirements.
- Define lifecycle ownership.
- Test credential behaviour across normal and recovery states.
Distinguish Different Types of Secrets
Not every secret has the same purpose or lifecycle. A user password authenticates a person. A device credential can establish product identity. An API token can authorise service access. A cryptographic key can protect confidentiality, integrity or update authenticity. Build and signing secrets protect the production pipeline. Treating all of these as one generic credential category can create unsafe reuse and unclear ownership. The design should identify what each secret protects and which component is allowed to access it.
- User credentials.
- Device or product credentials.
- API tokens.
- Cryptographic keys.
- Build and deployment credentials.
- Signing material.
Avoid Unnecessary Shared Default Credentials
Shared default credentials create systemic risk because compromise of one known value can expose many deployed products. ENISA's Secure by Design and Default Playbook specifically supports unique device identity and secrets by default. Depending on the product, safer approaches can include unique per-device credentials, secure enrolment or user-established credentials during onboarding. The exact approach should reflect the product architecture and cybersecurity risk assessment.
- Avoid universal shared credentials where not justified.
- Consider unique device credentials.
- Use secure onboarding.
- Protect credential provisioning.
- Verify credential uniqueness where required.
Do Not Embed Operational Secrets in Source Code
Operational credentials, API tokens, private keys and signing material should not be stored as ordinary source-code constants or committed into repositories. Source history can persist values even after they appear to be deleted. Development workflows can use secret scanning to detect accidental exposure, while sensitive values should be supplied through controlled provisioning or secret-management mechanisms. When a real secret is exposed, remediation normally includes rotation or revocation rather than only deleting the visible string.
- Keep operational secrets out of source code.
- Use secret scanning.
- Control access to sensitive values.
- Rotate or revoke exposed secrets.
- Review repository history where exposure occurs.
Protect Secrets at Rest and During Use
A credential can be generated securely and still be compromised through weak storage. Product design should determine where secrets are stored, which process or component can access them and what protections exist against extraction or modification. Depending on the product, controls can include operating-system credential stores, hardware-backed storage, restricted file permissions, cryptographic wrapping or isolated security components. The appropriate mechanism depends on the threat model and consequences of compromise.
- Identify where each secret is stored.
- Restrict access to authorised components.
- Protect confidentiality where required.
- Protect integrity where required.
- Review exposure through logs, diagnostics and backups.
Design Rotation Before a Credential Is Compromised
Credential rotation is easier when the architecture supports it from the beginning. Products should define how security-sensitive credentials can be replaced, how new credentials are authenticated, whether old credentials remain valid temporarily and how distributed components synchronise the transition. Rotation may be periodic for some secrets and event-driven for others. The important design objective is to avoid making credential replacement so disruptive that compromised secrets remain active unnecessarily.
- Define rotation triggers.
- Define replacement authority.
- Authenticate replacement operations.
- Define transition behaviour.
- Test rotation across relevant product states.
Revocation Needs a Separate Design
Rotation replaces a credential, while revocation determines that an existing credential should no longer be trusted. Products using certificates, tokens, device identities or administrator credentials should define how compromised or obsolete credentials become invalid. In distributed or intermittently connected products, revocation behaviour may require special design because every component may not receive status changes immediately. The expected security behaviour should be documented rather than left to implementation assumptions.
- Define when credentials are revoked.
- Define how revocation information reaches components.
- Define offline behaviour.
- Test access after revocation.
- Record recovery procedures.
Reset and Recovery Must Not Restore Unsafe Secrets
Product reset and account recovery can accidentally recreate insecure credentials. A reset process that restores one universal password or long-lived shared token can undermine the secure baseline. Teams should define what happens to device identities, user credentials, cryptographic material and service tokens during reset. Recovery mechanisms should also avoid becoming an easier path around normal authentication than the primary login process.
- Define credential behaviour after reset.
- Avoid restoring unsafe shared credentials.
- Protect account recovery.
- Review device identity behaviour.
- Test recovery against abuse scenarios.
Build and Signing Secrets Need Stronger Separation
Build, release and signing credentials can have authority over many product versions and therefore deserve particular protection. These secrets should be separated from ordinary developer credentials, restricted to appropriate release processes and protected from uncontrolled export. CI/CD systems should expose them only to authorised jobs or environments. A compromise of release-signing material can undermine the integrity of the update or distribution process even where product source code is secure.
- Separate release credentials from developer accounts.
- Restrict signing authority.
- Protect CI/CD secret access.
- Audit important signing operations.
- Plan key replacement and incident response.
Maintain Credential-Lifecycle Evidence
Useful development evidence can include credential architecture, provisioning design, secret-storage decisions, access-control boundaries, rotation and revocation tests, reset tests and secret-scanning results. The evidence should show how credentials support the product's Annex I security outcomes rather than merely listing the secret-management technology used. Significant exceptions, such as a shared credential retained for a product-specific reason, should have a documented risk rationale.
- Credential architecture.
- Provisioning design.
- Storage and access controls.
- Rotation and revocation tests.
- Reset and recovery tests.
- Secret-scanning results.
Official sources
Read the full legal text and Commission material for precise wording, qualifications and updates.