Annex I Part I (2)(b) CRA secure by default configuration

What secure by default configuration means under the CRA

Under the Cyber Resilience Act, a manufacturer that places a product with digital elements on the EU market must show that the product is delivered with a secure by default configuration, and that the product can be returned to its original, secure state. The point is about the settings a customer gets out of the box, before anyone has tuned anything. The requirement does not ask for a particular setting list. It asks the manufacturer to decide, on the basis of its cybersecurity risk assessment, which defaults expose the product to risk and to change them before release. The main exception is a tailor-made product where the manufacturer and the business user have agreed otherwise in writing, so the agreement itself becomes evidence.

The risks this point addresses are familiar to anyone who has audited a device or server fleet: default administrative credentials that were never changed, management services listening on every network interface, debugging ports left open, and weak cryptographic options such as old protocol versions or deprecated algorithms still enabled because removing them broke an early integration. Each of these turns a product into an easy target at installation time. The reset requirement addresses the other side of the same problem. A customer who suspects a compromise, or who is handing a device to someone else, needs a route back to the factory state that does not depend on the original vendor's support desk.

The difficulty is rarely the requirement itself. Defaults are usually set by engineering teams years before the product is reviewed for the CRA, often in a configuration file that nobody has read since the first release. Modern products also expose far more options than anyone can review by hand, spread across installers, web consoles, APIs and config files. Start by inventorying every default that the risk assessment flags as security relevant, record the current value, and decide which values change. Then confirm with the product owner which deviations, if any, are covered by a written agreement with a business user. An independent assessor will ask for both lists, so keep them under version control alongside the release.

Which products, configurations and teams fall under secure by default

Point (2)(b) applies to the shipped state of every product, but the work it creates depends on what the product is, how it is first set up and who controls its defaults. The cards below name the scoping decisions that determine how much of a product's configuration the manufacturer must secure before release.

Products with network interfaces and accounts

Any product that opens a listening port, exposes a web console or creates user accounts has defaults that an attacker can reach on day one. Inventory every interface and account type the product ships with, then decide which must be enabled at delivery and which can stay off until the user turns them on. Each default that exposes a service needs a documented reason in the risk assessment. Confirm this list against the product's actual build, not the design document.

First-run setup and initial credentials

The first start of a product is where default passwords, unsecured administrative access and open setup pages do the most damage. Decide whether the product forces a unique credential at first login, generates one per device or ships a fixed value that users must change. The chosen method changes the test cases, the user instructions required under Annex II and the evidence the manufacturer keeps.

Configuration profiles and deployment modes

Products often offer a development profile, an enterprise profile and a hardened profile, and the shipped default determines what most customers run. Document which profile is the default, what each profile enables and whether a less secure profile can be selected silently. Test the default profile as the baseline, because that is the configuration an assessor will check first.

Third-party and open-source components inside the product

A component can be secure in isolation and insecure once bundled, because the product's build or packaging re-enables features or ships older defaults. For components placed on the market separately, the regulation's guidance limits the obligation to the configuration the component is delivered with, while the integrator remains responsible for later changes. Trace each bundled component's default settings to the component version in the SBOM.

Configuration drift after release

A product that ships secure can drift when updates, migrations or restored backups reintroduce disabled features. Decide which settings must be re-applied on upgrade and which are preserved from user choices. Include the reset path in this decision, because restoring the original state is part of the requirement and must return the product to its secure default.

Teams that own the defaults

Engineering writes the defaults, product management decides which features ship enabled, and release management controls what reaches customers. When no team owns the final shipped configuration, defaults change quietly between releases. Assign a named owner for the default configuration, require sign-off from security and release management, and keep the approval record as evidence.

When the tailor-made exception and integrator rules apply

The point-(2)(b) duty to ship a secure by default configuration has one stated exception: a tailor-made product whose secure configuration the manufacturer and the business user have agreed otherwise. The exception is narrow. It applies only where the product is built for a specific business user, and the agreement must be in writing and must record which default settings differ from the standard secure baseline, who decided on each departure, and the reason it was accepted. Keep the agreement with the risk assessment under Article 13(2), because the departure is a risk decision that a market surveillance authority or notified body will expect to trace back to the analysis. Confirm with your legal and contract teams whether your current order forms or statements of work use the phrase tailor-made in a way that would qualify, or whether a standard product is being sold with bespoke terms.

Components sold on their own raise a different question. Commission FAQ 4.2.4 says that for components placed on the market separately, the obligation covers only the configuration the component is delivered with, not later changes made by the integrating manufacturer. Two examples in the FAQ illustrate the point. A cryptographic library shipped with deprecated algorithms disabled and certificate validation enabled by default meets the requirement at delivery, even if an integrator later re-enables weaker options. A microcontroller shipped with its network interfaces disabled by default meets it in the same way. The integrator, as manufacturer of the final product, then owns the configuration it ships. Check that your component supply terms and integrator documentation state the delivered default configuration explicitly, and that the integrator guidance required by Annex II point 8(a) describes the steps needed to keep that configuration secure after commissioning.

How an assessor tests secure by default configuration

This table compares five checks an assessor is likely to run against point (2)(b), with the evidence each one asks for and the findings that usually come up. Read each row as a test the manufacturer should be able to pass on paper before an assessment starts. The main takeaway is that the test is run on the product as delivered, so the evidence has to match the shipped configuration rather than a development build.

Test area	What the assessor checks	Evidence requested	Common findings
Factory state (fresh install or first boot)	Whether the product as delivered has risky features, default credentials, open interfaces or weak algorithms enabled out of the box	Documented default configuration per release, screenshots or exported config from a clean install, list of services and ports open at first boot	Default passwords still set, debug or remote services enabled, legacy protocols active in the shipped image
Reset to original state	Whether the user can return the product to its original secure configuration, and whether the reset works as documented	Reset procedure in user documentation, test record of a reset on a configured unit, description of what the reset restores and what it leaves untouched	Reset restores insecure defaults, reset path undocumented, reset keeps old credentials or certificates without warning
Tailor-made product agreement	Whether a deviation from secure defaults rests on a genuine agreement with the business user for a tailor-made product	Signed or recorded agreement, scope of the tailor-made product, link to the risk assessment and to the technical documentation	No written agreement, agreement too broad to cover the deviation, deviation used for a standard product rather than a tailor-made one
Initial commissioning instructions (Annex II, point 8(a))	Whether the user instructions explain the steps needed at first setup to keep the product in its secure configuration	Commissioning section of the user instructions, checklist of settings the user must change, version match with the shipped release	Instructions silent on changing defaults, steps out of date with the current release, security steps buried or missing
Component defaults (separately placed components)	Whether a component delivered to an integrator ships with its own secure configuration, limited to what the component is delivered with	Default settings of the component build, documented defaults for deprecated algorithms and certificate validation, statement of the delivered configuration	Deprecated algorithms enabled by default, certificate checks off, network interfaces on, integrator changes wrongly attributed to the component maker

How to implement secure defaults step by step

This sequence turns the Annex I Part I (2)(b) requirement into a documented, tested baseline, so every product release ships with secure defaults and a verified way back to its original state. Each step leaves a record that an assessor or market surveillance authority can follow.

Inventory every default setting
Engineering and product owners list each configuration option the product ships with, including credentials, network listeners, enabled protocols, cryptographic algorithms, certificate validation, logging levels, update behavior and debug features. Each entry records its default value, the component that owns it and whether a user can change it. The output is a default settings register, reviewed by the security lead. The step is done when every shipped option appears in the register and no option is left without an owner.
Classify defaults against the risk assessment
Using the cybersecurity risk assessment required by Article 13(2), the team marks which defaults carry security impact and records the reason for each. Settings that expose interfaces, weaken cryptography or disable authentication are flagged for hardening. The output is a classified register that links each security-relevant default to the risk it addresses. The step closes when the security lead has signed off each classification and any accepted residual risk is documented.
Define the hardening baseline
The team writes the target configuration for the product as a baseline: deprecated algorithms disabled, certificate validation enabled, unused services and ports off, and privileged features requiring explicit enablement. Where a recognized benchmark applies, the team maps its settings to the baseline and records any deviation with a reason. The output is a versioned hardening baseline. It is complete when each flagged default has a target value and an approver has accepted the baseline.
Build the baseline into the product
Developers apply the baseline in the build or packaging pipeline, so the release image or firmware ships with the hardened values rather than relying on documentation to change them. Configuration changes are tracked in version control and reviewed like code. The output is a build that starts in the hardened state. The step is done when a fresh install from the release artifact matches the baseline with no manual steps.
Design and build the reset to original state
Engineering designs a reset path that returns the product to its shipped, secure configuration, and it removes user data and settings where the product's purpose requires that. The design states what is restored, what is kept, how the reset is authorized and how it avoids leaving stale credentials behind. The output is a reset specification. The step closes when the specification is reviewed against the data removal requirement in Annex I Part I (2)(m).
Document secure configuration for users
Technical writers describe the measures users must take at initial commissioning and throughout the product's lifetime to keep it securely configured, as Annex II point 8(a) asks. Instructions cover what changes from the default, what the reset does and when to use it, and which settings an integrator must keep. The output is a reviewed user instruction set. The step is complete when each default that a user can change is covered and the instructions match the baseline version.
Verify defaults and reset in release testing
QA runs automated checks against the built release to confirm each baseline value is in place, then performs the reset on a configured test unit and confirms the restored state matches the specification. Results are logged with the build identifier, tester, date and any failures with their fixes. Where an endpoint or configuration scanner is used in the test environment, its policy results can serve as supporting records. The output is a reset test record and a signed-off release baseline check. The release is not approved until both pass.
Keep the baseline current through the support period
Each security update, dependency change or new feature is checked against the hardening baseline before release, and any new default is added to the register. The team reviews the baseline on a schedule it sets in its own process and retests the reset after material changes. The output is a change log of baseline revisions with approvals. Confirm with your conformity assessment body or market surveillance expectations which records they will ask to see for the full support period.

How Wazuh and Fleet can check and record default configuration

Secure by default is a property of the shipped product, but the configuration of the systems that run it is checked after deployment. Wazuh and Fleet can each check configuration on endpoints in the client's own environment and record the results as dated evidence. Neither tool inspects the product image itself, so each card names what the reader must confirm before relying on the output.

Wazuh configuration assessment policies

Wazuh Security Configuration Assessment scans monitored endpoints against YAML policies. The policies are mostly based on CIS benchmarks and can be extended with custom checks covering files, directories, registry keys and running processes. Each scan reports failed checks with remediation guidance. Confirm that a custom policy exists for each default setting your product ships with, such as disabled services, protocol versions and file permissions, because a benchmark check will not test product-specific defaults. Wazuh is licensed under GPL-2.0-only.

Fleet policies as yes or no queries

Fleet policies are yes or no questions asked of devices as osquery queries. A policy might ask whether a firewall is enabled or whether a disallowed service is running. The policies page shows which devices in each fleet pass or fail each policy, which gives a current view across the estate. Write each policy so it tests a specific default you have documented in the product's secure configuration baseline. Fleet is licensed under MIT.

Scan results as configuration evidence

Wazuh scan results and Fleet policy pass or fail records can show an assessor that defaults were present on a given date across a set of devices. Keep exported reports with timestamps, the policy version used and the device group they cover. Store them with the baseline document they test so the link between the requirement and the result is clear. These records show deployed state, so pair them with the vendor's shipped configuration documentation.

Coverage of the shipped product

Endpoint checks cover the systems where the product runs, not the product image delivered to customers. Confirm which defaults you can test on a running instance, which require inspecting the build or installer, and which can only be verified in the vendor's own test harness. Record any default that no tool can observe, and document the manual verification step for it in the technical documentation.

Components delivered to integrators

For a component delivered separately, the obligation covers the configuration the component ships with, as the Commission FAQ explains. An integrator's later changes fall outside it. Use endpoint scans in the integrator's environment to show that the delivered defaults survived deployment, and note in the user instructions which settings the integrator must keep. This separates the manufacturer's evidence from the integrator's own hardening.

What meeting secure by default configuration costs

This table breaks the effort behind Annex I Part I (2)(b) into cost components, showing who is paid for each, whether it is one-time or recurring, and what moves it up or down. No figures are given because none are supplied for this requirement, so use the right-hand column to shape what you ask for in a written quote. The main takeaway is that most of the cost sits in defining and keeping the baseline current across releases, not in the first build.

Cost component	One-time or recurring, and who is paid	What drives it up or down
Engineering time to define the secure baseline	One-time for the first release. Internal engineers or an implementation partner, billed on the written scope.	Number of product variants, configuration options and components. Fewer defaults to decide and a documented hardening standard shorten it.
Hardening and configuration work	One-time, then recurring with each major change. Internal or partner engineers.	Count of network interfaces, services and cryptographic settings that ship enabled. Disabling unneeded features early reduces rework.
Tooling and licenses	Recurring where commercial. Vendor licenses or subscriptions, or none for self-hosted open source.	Choice of configuration assessment tooling. Self-hosted open-source options such as Wazuh (GPL-2.0-only) or Fleet (MIT) remove license spend, but hosting and staff time remain. Confirm licensing terms in writing.
Reset and first-run test effort	One-time per product line, then recurring at each release. Internal QA or testers.	Number of reset paths, restore points and first-boot scenarios. Automated test cases for factory reset make regression testing cheaper.
Documentation of initial commissioning	One-time, then updated with each release. Technical writers or engineers, as Annex II point 8(a) requires user instructions for secure setup.	Number of deployment models and user roles. Reusing a single commissioning checklist across products keeps this manageable.
Evidence upkeep across releases	Recurring for the whole support period. Internal compliance staff or a retained partner.	Release frequency, number of products and how well configuration evidence is generated automatically. Ask whether evidence is produced from pipelines or assembled by hand.
External review of the baseline	Periodic or one-time. Independent security testers, paid on scope.	Scope of the review, whether it covers reset and default-state checks, and how many products are included. Ask for the review scope in writing.
Auditor or notified body sampling	Recurring where an independent assessment applies. Paid to the independent body, not to the implementation partner.	Product class, the conformity route and how many configuration samples are requested. Ask the body which evidence it will sample before the engagement starts.

Evidence that shows secure defaults and how to keep it current

Secure defaults are only as credible as the records behind them. The cards below cover the artifacts an assessor or market surveillance authority is likely to ask for, and how often each one needs to be refreshed across the support period. Treat them as one connected set: the register and baseline define the defaults, the test records prove them, and the user-facing documents carry them to the people who deploy the product.

Default settings register

A register lists every configurable setting in the product, its shipped value, the value after reset, and the reason the shipped value was chosen. It is the anchor for the whole requirement, because it shows that each default was decided rather than inherited. Check that every setting that touches authentication, cryptography, network exposure, logging or data retention has an entry, and that each entry names the owner who approved it. Review the register at every release and whenever a new interface or dependency adds configuration.

Approved hardening baseline

The hardening baseline is the approved target state for the product's default configuration, covering services, ports, protocols, cipher suites and deprecated algorithms. It is the reference an assessor compares the shipped configuration against. Confirm that the baseline is version controlled, that exceptions carry a documented justification, and that a named role signs off changes. Refresh it when standards for cryptography or protocol support change, and at least at each planned major release.

Automated configuration assessment results

Automated configuration checks compare the built product, or a reference installation, against the baseline and record pass or fail for each rule. Wazuh's Security Configuration Assessment, for example, uses YAML policies that check files, directories, registry keys and running processes, and it can be extended with custom policies. Keep the policy version and the scan output for each release candidate, and investigate any failing check before shipment. Rerun the scan on every release and on a fixed schedule for supported versions, since new vulnerabilities in configuration guidance appear after release.

Reset and factory-state test records

Reset records show that the product can return to its original state, as point (2)(b) requires, and that the reset removes user changes without leaving residual settings behind. Record the test procedure, the starting state, the reset steps, the resulting configuration diff against the register, and any data that persisted. Test the reset on each supported hardware or software variant. Repeat the test whenever the configuration store, update mechanism or data model changes, and at least before each release.

Tailor-made agreements with business users

Point (2)(b) allows a different arrangement for a tailor-made product when the manufacturer and business user agree otherwise. The signed agreement should state which defaults were departed from, the reason, the security consequences the user accepted, and who is responsible for any hardening afterwards. Keep one record per contract, and check whether the agreement still reflects the product after an update. Ask counsel to confirm how the agreement interacts with contract terms on warranties and liability before relying on it.

Integrator documentation for separate components

Where a component is placed on the market separately, the Commission's FAQ 4.2.4 limits the obligation to the configuration the component is delivered with, not later changes made by the integrating manufacturer. The evidence is therefore a delivery record for each component version, showing its shipped defaults, plus integration notes that tell the integrator which settings to review. Confirm with the Commission FAQ how your component's defaults are scoped before you rely on this split of responsibility.

Commissioning instructions and release test results

Annex II point 8(a) requires user instructions to describe the measures needed at initial commissioning and throughout the product's lifetime to ensure secure use. Keep the instruction set versioned with the product, and test that each step matches the shipped configuration on a clean install. Pair this with release test results that confirm the defaults and reset behavior in each build. Ask for the instructions to be reviewed whenever a default changes, so the documentation never describes a state the product no longer ships in.

Who owns the work for secure defaults

The manufacturer owns the requirement. Under Annex I Part I point (2)(b), the product must be made available with a secure by default configuration and a way to reset it to its original state, unless the manufacturer and a business user agree otherwise for a tailor-made product. Only the manufacturer can decide what the default is, which features ship enabled, and whether a tailor-made exception applies. Those decisions should be recorded in the cybersecurity risk assessment and the technical documentation.

Default decisions: Product management and security decide which features, interfaces and services are enabled at first start, and document why.
Reset behavior: Engineering defines what a factory reset restores and confirms that it returns the product to its original secure state.
Exceptions: Legal and product owners record any tailor-made agreement with a business user in writing.
Component handling: For components sold separately, the team confirms the shipped configuration and states what integrators must keep unchanged.
Instructions: The team writes the commissioning and lifetime guidance that Annex II point 8(a) requires.

Check that every default decision has a named owner and a linked record in the technical documentation.

Questions about secure by default configuration and the CRA

How much effort does secure by default configuration take under the CRA?

The effort depends on how many configurable settings the product has, how many of them ship in an insecure state today, and how much of the product your team controls directly. Work usually splits into a review of default values, changes to shipped configuration, a reset path to the original state, and user instructions covering secure setup. Each cost is a labor cost paid to whoever performs the work, plus any testing needed to show the shipped state holds across builds. The most reliable way to size the work is a written scope that lists the products, configuration surfaces and deliverables. Ask any provider to itemize these items in the quote so you can see which parts are one-time and which recur with each release.

Can we meet the secure by default requirement in-house?

Many organizations can do part of the work in-house, particularly when they already own the product's configuration files, build pipeline and release process. The harder parts are usually an independent review of defaults against the manufacturer's cybersecurity risk assessment and assembling evidence an assessor can follow. Your team owns the decision about which defaults are acceptable, and that decision must be documented. An implementation partner can prepare systems, configuration and evidence, but the manufacturer remains responsible for its controls. Decide early which tasks sit with your engineers and which you want to buy as fixed-scope work with written deliverables.

What does the work need from product and engineering teams?

Product management needs to name the intended use, the business users and any tailor-made arrangements agreed with them, because those agreements can change what the default must be. Engineering needs to identify every setting that affects security, such as network interfaces, cryptographic options, logging and authentication, and to explain why each default has its shipped value. Release management must keep the secure configuration in place for each build and record any change. Support and documentation teams need to describe the measures required at commissioning and across the product's lifetime. Agree on owners for each of these tasks before the work starts so that no default is left without an accountable person.

How long does this take relative to a release cycle?

Timing depends on whether defaults are reviewed once before a release or continuously across releases. A review that runs alongside a planned release is usually easier to fit than a retrofit of a product already in the field, which may need configuration changes shipped as updates. The regulation's dates matter here: the main obligations apply from 11 December 2027, according to Article 71(2) of Regulation (EU) 2024/2847, but products designed now will carry their shipped configuration through that date. Ask any provider for a timeline tied to your release calendar and to named milestones, and confirm the assumptions behind it. A duration is only meaningful when it is written into the agreed scope.

Are open-source components covered by the secure by default requirement?

Open-source components are covered to the extent they are part of a product you place on the market, but the scope depends on how the component reaches the product. The Commission's FAQ 4.2.4 says that for components placed on the market separately, the obligation covers only the configuration the component is delivered with, not later changes made by the integrating manufacturer. Its examples include a cryptographic library shipped with deprecated algorithms disabled and certificate validation enabled by default. Your team should inventory which components are shipped as delivered, which are altered in your build, and which are configured by your integrators. Confirm the treatment of free and open-source software with the current Commission guidance and with counsel before relying on any position.

What should a partner include in the written scope?

A written scope should name the products, versions and configuration surfaces in the engagement, the review method, and the deliverables the manufacturer will hold. Expect the scope to list the shipped default for each relevant setting, the reasoning behind it, the reset path to the original state, and the user instructions for secure commissioning. It should also state what is excluded, such as tailor-made products covered by agreement with business users, and which party owns each evidence item. Ask for milestones, acceptance criteria, and a statement of who performs ongoing checks after release. DeployOpen plans and delivers this work as fixed-scope engagements, with scope, deliverables and timelines agreed in writing before work starts, and a quote follows from that written scope.

Which evidence shows that a product ships with secure defaults?

Evidence should show the shipped state, not just the intent. Useful items include the default configuration files for each release, a record of how each default was chosen against the risk assessment, test results showing the defaults hold in the built artifact, and the reset procedure with proof that it returns the product to its original state. For fleets you operate, configuration compliance checks can produce ongoing evidence. Wazuh's Security Configuration Assessment, licensed GPL-2.0-only, scans endpoints for misconfigurations using YAML policies and recommends remediation, and Fleet policies (MIT) ask yes or no questions of devices and show which ones pass. Confirm with the assessor which evidence format they accept before building the set.

What risks come with leaving default settings unreviewed?

The main risk is shipping a product whose out-of-box state exposes services, weak cryptography or unnecessary interfaces that an attacker can reach before the customer hardens it. Under the regulation, penalties for breaches of Annex I are high: Article 64 sets maximum administrative fines of EUR 15 million or 2.5% of total worldwide annual turnover, whichever is higher. A less visible risk is that integrators and customers assume a default is safe when the manufacturer never documented it. Reviewing defaults against the risk assessment and writing down the reasoning reduces both risks. Ask any provider how they will record each default decision so that the decision can be defended to a market surveillance authority.

How DeployOpen prepares secure default evidence

DeployOpen plans, implements and documents self-hosted open-source platforms inside your own infrastructure, so the secure default configuration of each platform can be defined, built and evidenced before release. We prepare the configuration baseline and its evidence, while your organization keeps ownership of the product decisions and the conformity assessment.

How we scope

Engagements are fixed-scope, with the platforms, configurations and deliverables for point (2)(b) agreed in writing before work starts.
We confirm which components ship to you and which ones you deliver to integrators, since that boundary sets the configuration we must cover.
We agree with you which settings are tailor-made and were agreed with a business user, and record that agreement in the scope.

How we build

We set the shipped configuration so unneeded services, network interfaces and deprecated options start disabled, and document each default.
We build a reset path that returns the platform to its original configuration, and test that the reset restores the documented baseline.
We script compliance checks against the baseline, using tools such as Wazuh Security Configuration Assessment or Fleet policies, where they fit your environment.

How we hand over

You receive the baseline configuration, the default settings register, the reset procedure and the test results mapped to each setting.
We draft the user instructions covering secure commissioning and lifetime use, for your review and approval before release.
Your organization decides what to accept, signs off the technical documentation, and remains responsible for the conformity assessment.

How we support

Ongoing support, upgrades and continuous testing are available as retainers, so baselines stay current with each platform release.
We re-run the baseline checks after upgrades or substantial changes and update the default settings register to match.
Ask us to confirm the scope of any retainer in writing, including how configuration changes are tracked and who approves them.