The existing secure-default requirement answers what security posture the product should start with. Configuration management answers how the manufacturer defines, versions, changes, verifies and maintains that posture across real product releases.
Configuration Management Is Broader Than the Secure-Default Requirement
Annex I Part I point 2(b) requires a secure-by-default configuration where applicable and based on the cybersecurity risk assessment. Secure configuration management is the engineering discipline used to keep that intended posture controlled throughout development and release. It includes defining the baseline, identifying security-sensitive settings, governing changes, managing variants, testing the delivered state and preventing accidental drift. This development-process focus is different from a requirement explainer describing the legal mechanics of point 2(b).
- Define the approved security baseline.
- Identify security-sensitive configuration.
- Control configuration changes.
- Verify the final distributed state.
Define an Approved Security Configuration Baseline
The baseline describes the security-relevant state that product teams intend to ship or make available. It can include enabled services, exposed interfaces, account states, privilege settings, update behaviour, debug features, communication security and other configuration that materially affects risk. The baseline should be specific enough to verify but flexible enough to support controlled product variants where those variants have different legitimate deployment requirements.
- List security-sensitive settings.
- Define approved values.
- Identify product or edition scope.
- Assign configuration ownership.
- Version the baseline.
Separate Required Variants From Configuration Drift
Products may legitimately have multiple configuration profiles for different hardware models, deployment environments or customer types. A controlled variant has a defined purpose, approved settings and known security assumptions. Configuration drift is different: it occurs when the actual product state moves away from the approved baseline without a controlled design decision. Configuration management should make this distinction visible so legitimate variants are not mistaken for errors and accidental weakening is not accepted as normal variation.
- Document approved variants.
- Define security assumptions for each variant.
- Track which releases use each baseline.
- Detect unapproved differences.
- Review security consequences of new variants.
Treat Security-Sensitive Configuration as Controlled Product Code
Configuration files, deployment manifests, firmware options, build flags and policy definitions can alter product security as much as source-code changes. Where practical, security-sensitive configuration should therefore use similar controls to code: version history, peer review, testing and controlled approval. Configuration-as-code techniques can make changes more visible and reproducible, but the CRA does not require a particular tooling model. The important result is traceability and controlled change.
- Version security-sensitive configuration.
- Review important changes.
- Test changed configuration.
- Preserve change history.
- Restrict unauthorised modifications.
Review Changes That Expand Attack Surface
Configuration changes can enable new listening services, management interfaces, optional protocols or debug functions without changing application logic. Because Annex I includes attack-surface limitation, configuration change review should identify settings that expand external interfaces or privileged functionality. Enabling a new interface should trigger the same security questions as adding the feature in source code: who can reach it, how access is controlled and whether it is necessary for intended use.
- Review newly enabled services.
- Review remote administration.
- Review debug and diagnostic features.
- Review optional protocols.
- Update testing when exposure changes.
Protect Configuration Integrity
Annex I requires protection of configuration against unauthorised manipulation or modification. Product design should therefore consider who can change security-sensitive settings, how changes are authenticated and authorised, whether configuration integrity can be verified and how unauthorised changes are detected. The appropriate mechanisms depend on product architecture, but configuration should not become an unprotected path around otherwise strong security controls.
- Restrict configuration changes.
- Authenticate administrative changes.
- Authorise changes by role.
- Protect stored configuration integrity.
- Record important security changes where appropriate.
Validate Configuration During Build and Packaging
The intended baseline can be weakened during build or packaging through environment-specific flags, test credentials, debug settings or deployment templates. CI/CD can verify important configuration properties in the built artefact rather than checking only source files. This can include service exposure, permissions, configuration files, enabled modules and debugging features. Verification should identify the exact artefact tested.
- Inspect built artefacts.
- Detect debug or test settings.
- Verify expected services.
- Verify permissions.
- Tie results to the release artefact.
Test Reset and Recovery Against the Baseline
If a product can be reset to its original state, the reset path should restore the intended secure baseline rather than an obsolete or weaker historical configuration. Recovery images, factory defaults and configuration migration code should therefore be included in security testing. Product teams should also distinguish resetting configuration from deleting user data because these operations can have different purposes and legal implications.
- Define the expected reset baseline.
- Test factory or recovery images.
- Verify credential behaviour.
- Verify service and privilege settings.
- Retest after baseline changes.
Monitor Configuration Drift Where the Manufacturer Controls Deployment
For products or services where the manufacturer controls the deployed environment, configuration monitoring can detect drift from approved security baselines. The CRA does not require one universal drift-monitoring technology, and manufacturers may have limited control after some products are sold. Where monitoring is technically and operationally available, it can identify disabled protections, newly exposed services or unauthorised changes that undermine the expected security posture.
- Identify settings suitable for monitoring.
- Detect important baseline deviations.
- Classify authorised and unauthorised changes.
- Escalate security-relevant drift.
- Respect product and deployment boundaries.
Configuration Changes Should Feed Back Into Risk Assessment
A configuration change can alter the assumptions behind the cybersecurity risk assessment even when product code is unchanged. Enabling remote administration, changing authentication requirements or exposing an additional interface can create new attack paths. Significant configuration changes should therefore trigger review of relevant threats, security requirements and tests. This keeps configuration management connected to Article 13 rather than operating as an isolated release activity.
- Identify risk-relevant configuration changes.
- Review affected threat scenarios.
- Review security requirements.
- Update tests where needed.
- Document material risk decisions.
Retain Configuration Evidence by Product Version
Useful evidence can include approved baselines, configuration change history, variant definitions, review records, build checks, release verification and reset tests. Evidence should identify the product version or artefact to which it applies. This allows the manufacturer to show not only that a secure baseline existed in documentation, but that the configuration distributed to users was actually checked against it.
- Approved baseline.
- Version history.
- Variant definitions.
- Change approvals.
- Release checks.
- Reset verification.
Official sources
Read the full legal text and Commission material for precise wording, qualifications and updates.