Security by design under the CRA — turn requirements into product work

“Security by design” is not a policy document to sign. For a product with digital elements it should be visible in design decisions, attack-surface reduction, secure defaults, update handling, testing and vulnerability management throughout the product lifecycle.

A practical model is straightforward: risk → requirement → design decision → action → test → result → evidence → review.

Translate essential requirements into product work

Annex I of the CRA contains essential cybersecurity requirements. In practical product work, teams need to address areas including:

designing the product with a level of cybersecurity appropriate to risk;
protection from unauthorised access;
confidentiality, integrity and availability of data and functions;
attack-surface reduction;
mechanisms that reduce the impact of an incident;
recording and monitoring relevant security-related activity;
secure removal of data and settings;
secure update distribution;
regular security tests and reviews;
coordinated vulnerability disclosure.

A checklist is a starting point. It is not evidence of execution.

Example: “protect from unauthorised access”

A weak record says:

“The system has authentication.”

An operational record can show:

Risk: compromise of an administrative account could change security-critical configuration.
Decision: privileged roles require a defined authentication and session-control mechanism.
Owner: a named person or team.
Implementation: link to the engineering change.
Test: scenario verifying the required behaviour.
Result: PASS/FAIL with product version and date.
Evidence: report, log, screenshot or test artefact.
Review: repeat assessment after changes to authentication or the risk profile.

Months later, the organisation can show not only what it intended to do, but what was actually verified.

Security by default

Default configuration matters because many users do not change security settings after deployment. CRA requirements address areas including secure configuration, updates and protective mechanisms.

For each security-significant function, ask:

what configuration a new user receives by default;
why that default is appropriate for normal use;
which protections can be weakened or disabled;
whether risky changes are understandable to the user;
whether the product can return to a secure state;
which test verifies the behaviour after installation and update.

Put security into the release process, not into documentation after the release

A release review should check at least:

whether the threat model or risk profile changed;
whether new dependencies were introduced;
whether security tests cover the change;
whether known vulnerabilities have documented decisions;
whether user security information is still accurate;
whether support-period assumptions and dependencies remain realistic;
whether evidence is attached to the correct product version.

If these questions are first asked during an audit, the organisation has a documentation process rather than security by design.

ENISA: repeatable actions instead of slogans

ENISA published its “Secure by Design and Default Playbook” for SMEs on 30 July 2026. The material focuses on turning principles into repeatable actions in existing engineering, product and release processes. The same principle works for CRA implementation: use the team’s real delivery process, then make ownership and evidence explicit.

How Pulsar supports an evidence-based workflow

Confirmed Pulsar areas — risks, controls, tasks, documents, evidence, audits, reports and analysis history — can connect a design decision to implementation, verification and review.

AI in Pulsar should remain an assistant for preparing drafts. It should not autonomously approve a risk assessment, security exception or product-compliance decision.

See Pulsar GRC on a requirement-to-evidence workflow

Sources

Sources checked: 12 September 2026.