Secure by design and secure by default answer different product-security questions under the Cyber Resilience Act (CRA). Secure by design asks whether security is built into architecture, development and lifecycle processes. Secure by default asks whether the product reaches the user in a defensible configuration without requiring the user to discover and enable basic protections.
For manufacturers, the practical objective is not another policy document. It is to make risk assessment, architecture decisions, implementation controls, verification, default configuration and retained evidence part of the normal product and release process.
ENISA's July 2026 Secure by Design and Default Playbook helps operationalise those principles through 22 execution-focused playbooks. Each contains an objective, checklist, minimum-evidence examples and release-gate criteria. ENISA presents the material as practical technical guidance, not as a substitute for applying the CRA to the manufacturer's product and risk context.
What the CRA requires
Article 13 requires manufacturers to perform a cybersecurity risk assessment and take it into account during planning, design, development, production, delivery and maintenance. Annex I then turns that lifecycle obligation into essential cybersecurity requirements.
Where applicable on the basis of the risk assessment, Annex I Part I requires products to address areas including:
- being made available without known exploitable vulnerabilities;
- a secure by default configuration, subject to the limited rule for tailor-made products agreed with a business user;
- security updates and, where applicable, automatic security updates enabled by default with a clear opt-out mechanism;
- protection against unauthorised access through authentication, identity or access controls;
- confidentiality and integrity protection for relevant data, commands, programs and configuration;
- data minimisation and protection of essential functions;
- limitation of attack surfaces and external interfaces;
- exploitation-mitigation measures;
- security-relevant recording and monitoring; and
- secure removal or transfer of data and settings.
The Commission's manufacturer guidance describes the same direction in operational terms: products should be foundationally secure, including security by default, access control, cryptography and security-update capabilities. Which Annex I requirements apply, and how they are implemented, depends on the manufacturer's product-specific cybersecurity risk assessment.
The consequence is important: secure by design and secure by default are risk-based engineering duties, not one universal checklist applied identically to every product.
Secure by design and secure by default are different controls
ENISA distinguishes the concepts usefully.
Secure by design concerns how the product is conceived, architected, implemented, tested, released and maintained. The aim is to prevent security from becoming a late layer around design decisions that have already created unnecessary exposure.
Secure by default concerns the security posture presented to the user. A product can have strong security mechanisms and still create avoidable risk if it ships with unnecessary services enabled, permissive access, shared credentials, unprotected communications or important protections disabled.
| Question | Secure by design | Secure by default | | --- | --- | --- | | Primary focus | Product architecture and lifecycle | Initial and ongoing configuration | | Starts | Requirements and design | Before first use and deployment | | Typical evidence | Threat model, architecture decisions, tests, SBOM, review records | Baseline configuration, enabled controls, onboarding flow, update defaults | | Release question | Are relevant security controls effective for this release? | Does a clean installation start from the intended secure baseline? |
The two disciplines reinforce each other. Restrictive defaults cannot compensate for uncontrolled trust boundaries, and sound architecture does not help enough if users must disable its protections to make the product work.
Start with threat modelling and trust boundaries
ENISA places trust boundaries and threat modelling early in its playbook because later controls depend on knowing which assets, interfaces, actors and data flows require protection.
A lightweight product threat model should identify:
- the product boundary and relevant external systems;
- assets whose compromise would matter to users or the intended purpose;
- trust boundaries between components, users, services and networks;
- credible attacker actions and misuse cases;
- security assumptions that the design relies on; and
- controls intended to prevent, detect, contain or recover from those scenarios.
This should not be a one-time workshop. Product changes that affect interfaces, privileges, dependencies, data flows or deployment assumptions should trigger review of the relevant threats and controls.
Evidence can remain lightweight: an architecture or data-flow diagram, a short threat register, linked security requirements and records of the controls selected for material scenarios. The useful chain is risk -> design decision -> implementation -> verification.
Build the architectural foundations
The ENISA playbook treats least privilege, identity, attack-surface minimisation and defence in depth as architectural foundations.
Least privilege and identity
Users, services and processes should receive only the permissions needed for their intended function. Product teams should know which identities exist, how credentials or device identities are provisioned and rotated, and where authentication and authorisation decisions are enforced.
Useful evidence includes role definitions, permission matrices, service identities, privileged-interface inventories and tests showing that unauthorised actions are rejected.
Attack-surface minimisation
Annex I requires products to limit attack surfaces, including external interfaces. In practice, teams should inventory exposed interfaces, remove unnecessary ones and justify those that remain.
A release review should be able to answer:
- Which network listeners and management interfaces are expected?
- Which diagnostic or development functions remain in production builds?
- Which optional components are active?
- Has the release introduced a new trust boundary or reachable path?
A port scan, interface inventory, production build configuration and architecture record can provide stronger evidence than a generic hardening statement.
Defence in depth
Controls should not assume one protection always succeeds. Authentication, privilege separation, integrity checks, isolation, input validation, exploit mitigations and monitoring should combine so that bypassing one layer does not directly become complete compromise.
The exact layers depend on the product. The engineering task is to make security assumptions explicit and identify single points where one failure would defeat all downstream controls.
Keep secure design alive through implementation and maintenance
A defensible architecture can still lose its security properties during implementation, release or maintenance. ENISA therefore includes secure coding, verification, logging, configuration management, vulnerability management and supply-chain controls within secure-by-design practice.
Security-relevant requirements need verification methods appropriate to the product. That may include code review, static analysis, dependency analysis, fuzzing, dynamic tests, protocol tests, hardware tests or abuse-case testing. The goal is not to run every tool; it is to connect each material risk or control to a verification activity capable of testing the intended behaviour.
Configuration and change management matter for the same reason. Production profiles, hardening settings, infrastructure-as-code and release configuration should make important security settings repeatable instead of dependent on undocumented manual work.
Secure by design also continues after shipment. CRA Annex I Part II requires vulnerability handling, while the product needs update and remediation mechanisms before the first field vulnerability appears. Third-party components, repositories, build systems and update channels therefore belong in the security model. SBOM information is useful when it stays tied to the actual product and release rather than existing as an isolated inventory.
Secure by default starts with the shipped state
ENISA describes secure by default as applying the most secure reasonable configuration automatically. The CRA's secure-by-default requirement provides the regulatory anchor; the risk assessment determines what that baseline means for the product.
Disable unnecessary services and features
Optional services should not be reachable merely because some users may need them. The baseline should expose only the functionality necessary for intended operation.
Evidence can include enabled-service inventories, production profiles, default firewall rules and automated tests confirming that development or optional interfaces are not exposed.
Restrict initial access
Shared administrative credentials and universal defaults create unnecessary exposure. Initial access should be deliberately constrained, and provisioning should avoid reusable secrets across an installed base.
For products without ordinary user accounts, the same principle applies to device certificates, API keys, pairing secrets, maintenance interfaces and recovery credentials.
Protect communications from first connection
If a product relies on authenticated or encrypted communication, the secure state should not require a user to operate it through an insecure protocol first. Certificate provisioning, trust anchors and bootstrap flows therefore belong in product design rather than only in deployment documentation.
Make security onboarding explicit
Some security choices depend on the deployment and cannot be predetermined by the manufacturer. In those cases, secure by default can mean requiring security-critical onboarding before exposure instead of silently accepting an unsafe placeholder configuration.
Examples include establishing an administrator credential, selecting trusted peers, confirming a security domain or provisioning device identity.
Automatic updates are risk-based, not universal
Annex I requires support for security updates and, where applicable, automatic security updates installed within an appropriate timeframe and enabled by default, with a clear opt-out mechanism and temporary postponement.
The CRA recitals explain why "where applicable" matters. Automatic updates are particularly relevant to consumer products, while products used in professional ICT networks and critical or industrial environments may have operational reasons not to update automatically.
That means secure by default should not be reduced to "always update automatically". For an industrial product, a defensible update model may instead combine authenticated update packages, clear notification, controlled deployment, rollback, assigned responsibility and a process preventing indefinite unreviewed deferral. The risk assessment should explain the chosen model.
Turn principles into evidence and release gates
One practical strength of ENISA's playbook is its repeated minimum evidence and release gate structure. It converts broad principles into demonstrable engineering work.
| Control area | Example evidence | Example release question | | --- | --- | --- | | Threat modelling | Threat model, architecture diagram, tracked assumptions | Did this release change a trust boundary or threat assumption? | | Least privilege | Permission definitions and access tests | Does any identity receive new privilege without justification? | | Attack surface | Interface inventory and production configuration | Did the release add or re-enable an exposed interface? | | Secure coding | Review records and targeted security tests | Are relevant findings resolved or explicitly accepted? | | Supply chain | Release-specific SBOM and dependency evidence | Do reviewed components match the release? | | Secure defaults | Baseline configuration and clean-install test | Does installation start in the intended secure state? | | Updates | Update-policy record and verification tests | Does the update path still behave as intended? | | Monitoring | Event catalogue and logging configuration | Are security-relevant events generated and protected? |
The evidence does not need to live in one repository. Existing engineering records can be reused if they are attributable to the correct product, variant and release.
A release gate should remain an engineering control, not an automatic legal decision. Some checks can be automated in CI/CD; others require accountable engineering judgement. Passing a technical gate does not itself determine CRA conformity.
A practical adoption sequence
A product team can integrate secure-by-design and secure-by-default work into existing lifecycle checkpoints rather than launching a separate compliance programme.
First, establish a baseline: define the product and release boundary, record the cybersecurity risk assessment and key threat scenarios, inventory interfaces and privileged paths, document the production default configuration, and identify existing security tests, SBOM outputs and update mechanisms.
Second, convert relevant principles into owned controls. For each control, record the owner, implementation mechanism, evidence produced by normal work, release criterion and review trigger.
Third, make release review incremental. Use product changes, the threat model and risk assessment to identify which controls are affected. Reuse valid evidence for unchanged areas and regenerate evidence where the release changed the security posture.
This keeps the process proportional while preserving lifecycle traceability.
Common mistakes
Treating secure by design as a final security review. If security architecture is reviewed only after implementation, the team is evaluating accumulated choices rather than shaping them.
Treating secure by default as a customer hardening guide. Instructions help, but baseline protection should not depend on every user finding and correctly applying optional hardening steps.
Using the ENISA playbook as proof of conformity. It is technical guidance and an implementation aid, not a replacement for the Regulation, applicable standards or conformity-assessment procedure.
Collecting evidence without product scope. A test report, SBOM or configuration snapshot is weak evidence if nobody can establish which product and release it describes.
Automating decisions that require judgement. CI/CD can verify deterministic controls, but risk acceptance, applicability decisions and legal conformity remain accountable manufacturer decisions.
Keeping requirements, security evidence, vulnerability work and release decisions connected to the exact product and lifecycle context is the operational problem behind these controls. AA-sec is designed around that traceability and is intended to complement existing engineering and delivery systems rather than replace them. The manufacturer remains responsible for engineering judgement and the legal CRA conformity decision.
Key takeaway
Under the CRA, secure by design and secure by default should become normal product-engineering behaviour rather than a late compliance exercise. Secure by design embeds risk-informed security into architecture, implementation, verification, supply-chain controls and lifecycle processes; secure by default ensures the product starts from a defensible security posture without transferring basic protection work to the user.
ENISA's 2026 playbook provides a practical execution model: define the principle, implement a focused checklist, retain minimum evidence and apply release-gate criteria. Those records can then be connected back to the CRA risk assessment and applicable Annex I requirements while the manufacturer keeps the legal conformity decision separate from the technical workflow.
Official sources
- Regulation (EU) 2024/2847 — Cyber Resilience Act — EUR-Lex
- ENISA Secure by Design and Default Playbook — ENISA
- Cyber Resilience Act - Manufacturers — European Commission
- Commission publishes new guidance to support timely Cyber Resilience Act implementation — European Commission