Secure configuration communication is the user-facing side of product hardening. It should explain which settings, deployment conditions and operating assumptions matter to security, how users establish the intended secure state, and which later changes can weaken it.
Start With the Intended Security Environment
Annex II point 4 requires information about the intended purpose of the product, including the security environment provided by the manufacturer. Secure configuration guidance should therefore begin by explaining the environment the product assumes, such as network placement, trusted administrative access, supported identity services, physical protection or dependency on another security control.
- Describe intended deployment conditions.
- Identify important trust assumptions.
- Explain required surrounding controls.
- Make unsupported environments clear where relevant.
Explain the Security Properties Users Can Configure
Annex II point 4 also requires information about the product's security properties. Where those properties depend on user configuration, instructions should identify the relevant controls and the secure state users should aim for. Examples can include authentication settings, access roles, encryption options, remote-management exposure, logging or update configuration.
- Identify security-sensitive settings.
- Explain the recommended secure state.
- Separate required controls from optional enhancements.
- Use names that match the actual interface.
Use Commissioning Instructions to Establish a Secure Starting State
Annex II point 8(a) requires necessary measures during initial commissioning and throughout the product lifetime to ensure secure use. Configuration guidance should therefore explain what must happen before ordinary use begins. That may include changing credentials, enrolling an administrator, applying current security updates, connecting to the intended network, disabling unnecessary exposure or confirming that secure defaults remain enabled.
- Initial identity and access setup.
- Current security-update state.
- Network and service exposure.
- Security-sensitive default settings.
Explain Which Defaults Should Normally Remain Enabled
Secure-by-default design and user communication serve different functions. Product design determines the default state, while user information explains what that state means and what can happen if users change it. Manufacturers should identify security-sensitive defaults that users may reasonably alter and explain the resulting security consequences without shifting responsibility for insecure defaults onto the customer.
- Identify security-relevant defaults.
- Explain consequences of disabling protections.
- Avoid requiring users to repair an insecure factory state.
- Keep instructions aligned with shipped product behaviour.
Communicate Known Risk-Producing Configurations
Annex II point 5 requires known or foreseeable circumstances that may lead to significant cybersecurity risks. Configuration guidance should identify material deployment or setting combinations that create such risks. Examples can include exposing an administrative interface directly to untrusted networks, operating without authentication, disabling integrity checks or using a configuration intended only for isolated test environments in production.
- Name material risk-producing configurations.
- Explain why the condition matters.
- Provide a safer alternative where possible.
- Prioritise risks users can realistically encounter.
Explain How Product Changes Can Affect Security
Annex II point 8(b) requires information about how changes to the product can affect the security of data. Configuration changes can alter access boundaries, encryption, exposure, data retention or integration behaviour. Instructions should identify important classes of change that require security review rather than assuming that all settings are operationally neutral.
- Administrative and access-control changes.
- Network exposure changes.
- Integration or extension changes.
- Changes affecting stored or transmitted data.
Separate Secure Configuration From Troubleshooting Shortcuts
Support documentation sometimes recommends temporarily disabling security controls to isolate a problem. If such steps are necessary, the instructions should make their temporary nature explicit and tell users how to restore the secure configuration. Permanent troubleshooting shortcuts should not quietly become the normal operating state.
- Label temporary security reductions clearly.
- Provide restoration steps.
- Avoid insecure permanent workarounds.
- Escalate recurring security-control conflicts to engineering.
Keep Configuration Guidance Version-Specific
Security settings can move, change meaning or disappear between releases. Manufacturers should tie secure-configuration guidance to the supported product versions to which it applies. Historical guidance should remain available where older supported branches still use different settings or interfaces.
- Identify applicable versions.
- Update screenshots or paths when interfaces change.
- Preserve supported historical guidance.
- Avoid applying current settings to incompatible older releases.
Test the Guidance Against a Real Product
Configuration instructions should be validated on the actual product. A security recommendation is not useful if the named setting does not exist, the order of steps is wrong or a documented change prevents normal operation. Product security and technical-writing teams should verify that representative users can reach the intended secure state by following the published instructions.
- Test the documented setup path.
- Confirm setting names and defaults.
- Check the resulting security state.
- Retest after major product changes.
Official sources
Read the full legal text and Commission material for precise wording, qualifications and updates.