The CRA states legal cybersecurity outcomes, not a universal technical specification for every product. Manufacturers therefore need a requirements-engineering layer that converts applicable legal outcomes and product-specific risks into measurable requirements for architecture, implementation, configuration, testing and release.
Start With the Cybersecurity Risk Assessment
Article 13 requires the cybersecurity risk assessment to inform how applicable Annex I requirements are implemented. Product security requirements should therefore not begin as a generic list copied from another product. They should begin with the risks associated with the product's intended purpose, reasonably foreseeable use, operating conditions, protected assets and expected lifetime. The requirement set should show how those risks are being treated in the product.
- Identify the relevant cybersecurity risk.
- Identify the applicable Annex I outcome.
- Define the security objective.
- Create one or more engineering requirements.
- Define how compliance will be verified.
Separate Legal Outcomes From Engineering Requirements
Annex I might require protection against unauthorised access, confidentiality, integrity, availability or attack-surface limitation. Those are legal cybersecurity outcomes. Engineering teams need more specific product requirements. For example, protection against unauthorised access may translate into requirements for administrator authentication, session handling, role enforcement and recovery. Keeping the legal outcome and engineering requirement distinct improves traceability because teams can change implementation details without losing sight of the underlying obligation.
- Record the legal requirement reference.
- State the product security objective.
- Create implementation-neutral requirements where practical.
- Record technical design choices separately.
Write Requirements That Describe Observable Behaviour
Requirements such as use strong security or provide secure authentication are difficult to implement consistently and difficult to verify. A useful product security requirement describes an observable product behaviour, constraint or property. It can specify who may perform an operation, which communication must be protected, what happens when verification fails, which interfaces may be enabled or which update packages the product will accept. The level of detail should be sufficient for engineering and testing without unnecessarily forcing one technology where several secure designs could work.
- Describe observable product behaviour.
- Identify actors or conditions where relevant.
- Avoid undefined adjectives such as strong or secure by themselves.
- Keep unnecessary implementation details out of higher-level requirements.
- Make the expected result testable.
Define Security Requirements for Trust Boundaries
Threat modelling often reveals trust boundaries where security requirements are needed. A network boundary can create requirements for authenticated communication and input validation. A privilege boundary can create requirements for authorisation and isolation. An update boundary can create requirements for authenticity and integrity verification. A third-party component boundary can create requirements for privilege limitation or update handling. Connecting requirements to these boundaries makes them easier to understand and maintain.
- Identify the trust boundary.
- Identify the security objective.
- Define required authentication or authorisation.
- Define confidentiality or integrity protection.
- Define validation or isolation where relevant.
Requirements Should Cover Failure Behaviour
Security requirements should describe not only the successful path but also important failure conditions. Authentication can fail. Certificates can expire. Update verification can fail. Dependencies can become unavailable. Configuration can be invalid. A requirement should define the expected secure outcome for important failure cases so developers do not invent inconsistent recovery behaviour during implementation. This is particularly important where failure could expose privileged access or undermine essential product functions.
- Define authentication failure behaviour.
- Define update-verification failure behaviour.
- Define invalid-configuration handling.
- Define recovery expectations.
- Protect privilege boundaries during failure.
Security Requirements Need Acceptance Criteria
A requirement becomes easier to manage when the team knows what evidence demonstrates that it has been satisfied. Acceptance criteria can identify successful and unsuccessful security behaviours, boundary conditions and expected logs or error states. The requirement does not need to contain every test case, but it should be specific enough that verification engineers can determine whether the implementation passes or fails. Ambiguous requirements create ambiguous release decisions.
- Define pass and fail conditions.
- Identify important negative cases.
- Identify expected security events or logs.
- Connect detailed test cases to the requirement.
- Define evidence required for release.
Assign Ownership to Security Requirements
Security requirements can disappear between teams if nobody owns their implementation and verification. Each significant requirement should have an engineering owner or owning component. Cross-cutting requirements may need coordination across several components, but responsibility should still be explicit. Ownership makes architecture review, implementation tracking and release decisions more reliable and helps teams respond when later product changes affect the requirement.
- Assign an engineering owner.
- Identify affected components.
- Identify the verification owner.
- Track implementation status.
- Define change-review responsibility.
Maintain Traceability From Risk to Evidence
A useful CRA requirements matrix can link the cybersecurity risk, applicable Annex I reference, product security requirement, implementing component, design control, verification method and evidence location. This does not mean every line needs a large compliance document. The objective is to make it possible to explain why the requirement exists and show that it has been implemented. Traceability also helps when a product change affects one component because teams can identify which security requirements and tests need review.
- Risk identifier.
- Annex I reference.
- Security requirement.
- Implementation owner.
- Verification method.
- Evidence location.
Keep Requirements Current as the Product Changes
Security requirements are not frozen at the first product release. New features, interfaces, components, deployment models and threat information can change the product's cybersecurity risks. Article 13 requires the cybersecurity risk assessment to be updated as appropriate during the support period. When risk assumptions change, related security requirements should also be reviewed. Requirement change control should therefore be connected to architecture and threat-model change triggers.
- Review requirements after security-relevant architecture changes.
- Review requirements after important threat findings.
- Review requirements after dependency or interface changes.
- Update verification where the requirement changes.
- Preserve version history.
Use Requirements to Support Release Decisions
Security requirements can provide the basis for release gates. Before release, the manufacturer can determine whether required controls are implemented, whether verification evidence exists and whether unresolved deviations are accepted through a controlled risk decision. This creates a direct connection between the cybersecurity risk assessment and the version that is actually made available on the market. It also reduces dependence on broad statements that the product is secure without showing which requirements were evaluated.
- Confirm required controls are implemented.
- Confirm verification evidence exists.
- Review failed or deferred security requirements.
- Document justified exceptions or residual risk.
- Tie approval to the released version.
Official sources
Read the full legal text and Commission material for precise wording, qualifications and updates.