Secure by Default Under CRA: Meaning & Annex I Requirements

Secure by default is one of the most important principles in the Cyber Resilience Act (CRA).

If secure by design ensures that a product begins its life with security built in, secure by default ensures that users receive a product that is already configured in the most secure way the moment they use it.

This principle is not about removing flexibility. It is about ensuring that safety is the baseline, not an optional extra.

This article explains what secure by default means under the CRA, why it matters, and how it connects to the essential cybersecurity requirements in Annex I.

Disclaimer: This content is provided for informational purposes only. The official text remains the authoritative reference.

What Secure by Default Means Under the CRA

Under the CRA, secure by default means that a product is delivered with settings that prioritise cybersecurity from the very first use.

Users should not be required to understand security trade offs, navigate complex configuration menus, or enable critical protections manually before the product becomes safe to operate.

In practice, secure by default means that the default configuration already reflects the outcome of the manufacturer’s cybersecurity risk assessment, based on the product’s intended purpose and reasonably foreseeable use.

Under the CRA, this requires that:

• essential security protections are active when the product is first used
• default settings do not unnecessarily weaken the product’s security posture
• users cannot end up in insecure states through accidental or uninformed actions
• exposure and attack surface are limited from the outset
• deviations from secure defaults require a deliberate and informed user decision

The core idea is simple.

A product must start secure, without requiring its users to become security experts.

How the CRA Describes Secure by Default in Annex I

Secure by default is defined in Annex I Part I of the CRA, which sets out the essential cybersecurity requirements that must be met before a product with digital elements can be placed on the EU market.

These requirements apply prior to market placement and are assessed as part of the conformity assessment process.

The most relevant Annex I requirements include the following.

Secure configuration from the start

Manufacturers must place products on the market with a configuration that already satisfies essential cybersecurity needs.

Security mechanisms should not depend on user activation. The default state of the product must already reflect the manufacturer’s risk assessment and mitigation decisions.

No weak initial settings

Products must not rely on default configurations that unnecessarily weaken security, such as:

• weak or universal default credentials
• exposed debug or administrative interfaces
• unnecessary external access paths
• unjustified data collection or data exposure

What qualifies as unnecessary depends on the product’s intended purpose and environment, but any default that increases risk without clear justification must be avoided.

Limited attack surface

Secure by default requires reducing the number of potential entry points available to attackers.

This means disabling or excluding any functionality, service, port, or interface that is not required for the product’s intended and reasonably foreseeable use.

The goal is not minimal functionality, but proportionate exposure.

Ability to restore a secure state

Users must be able to return the product to a secure default configuration.

This requirement protects against configuration drift, accidental misconfiguration, or security degradation over time. It also supports recovery after incidents or operational changes.

Automatic security updates active by default

Annex I also links secure by default to vulnerability handling.

Security updates must be provided and enabled by default, ensuring that known vulnerabilities are addressed promptly after release.

Users may deliberately opt out, and certain operational environments may justify constraints, but the manufacturer must ensure that the default behaviour prioritises timely security updates. Importantly, manufacturers are responsible for enabling updates by default, not for enforcing user installation.

Secure by Default in Practice

Secure by default affects both software and hardware products and shapes the initial user experience.

Common examples include:

• enforcing strong authentication or modern authentication methods at first use
• disabling remote access unless explicitly enabled by the user
• encrypting data automatically at rest and in transit
• restricting permissions for newly installed components
• blocking insecure or deprecated protocols
• limiting network exposure through conservative initial network settings
• providing clear, contextual security guidance within the product

The product should never rely on users discovering or enabling these protections themselves.

Why Secure by Default Matters for CRA Compliance

Secure by default is not a recommendation. It is a prerequisite for CRA compliance.

If a product does not meet the secure by default requirements of Annex I, it cannot successfully complete conformity assessment and cannot legally be placed on the EU market.

Beyond compliance, secure defaults significantly reduce:

• user driven misconfigurations
• security incidents caused by weak initial settings
• avoidable vulnerabilities present at release
• downstream operational and reporting burden once CRA reporting obligations apply from September 2026

Secure by default shifts risk prevention to where it belongs: before the product reaches users.

How Secure by Default Complements Secure by Design

Secure by design ensures that the architecture and development practices embed security throughout the lifecycle.

Secure by default ensures that those protections are actually active when the product is used.

Together, they form the foundation of Annex I and define what the CRA expects from manufacturers when bringing digital products to the EU market.

One without the other is insufficient.

How ScanDog Helps Teams Meet Secure by Default Requirements

Achieving secure by default requires visibility across code, dependencies, configurations, and vulnerabilities, all grounded in a documented risk based approach.

ScanDog supports this by helping teams:

• map dependency usage and reduce unnecessary components
• identify known exploited vulnerabilities that must not be present at release
• surface insecure default configurations that increase attack surface
• maintain visibility throughout both development and support periods

Secure by default becomes far easier to achieve when teams have a clear, continuous understanding of their product’s real security posture.

---