FprEN 40000-1-2, principles, product risk management, and lifecycle activities
The horizontal harmonised standard for the CRA product security and risk-management requirements, the essential requirements set out in Annex I Part I. It is tied to the first essential requirement of the CRA, on which the rest of the EN 40000 series builds.
FprEN 40000-1-2:2026 (CEN Formal Vote, August 2026)
Final draft at Formal Vote, no presumption of conformity yet
This assessment is structured to the emerging harmonised standard FprEN 40000-1-2:2026 (CEN Formal Vote, August 2026). That reference is a draft and is not yet cited in the Official Journal of the European Union, so following it does not confer presumption of conformity. It is used here as the working blueprint for a defensible, traceable assessment.
What FprEN 40000-1-2 covers
The standard sets out the cybersecurity principles, the risk-management methodology, and the product lifecycle activities that sit behind the CRA Annex I Part I essential requirements. Where FprEN 40000-1-3 governs how a manufacturer handles vulnerabilities once a product ships, this part governs how the product is designed, built, and maintained to be secure in the first place.
It is written to be process-agnostic, so the activities can run concurrently or in varying order and apply across development methodologies. The term product includes remote data processing solutions where applicable.
The four product cybersecurity principles
Clause 5, informative
Risk-based approach
Controls are chosen to match the risks to persons, organisations, and society, characterised by impact and likelihood across the product's intended purpose and reasonably foreseeable use.
Security by design
Cybersecurity is integrated from concept through the whole lifecycle, using techniques such as least privilege, attack-surface minimisation, defence in depth, and secure coding, never bolted on later.
Secure by default
The default configuration is secure for the intended purpose at the time the product is placed on the market, with non-essential services off, anti-rollback, and an easy reset to secure defaults.
Transparency
Adequate cybersecurity information reaches every interested party in an accessible, usable form, covering update availability, the current security state, residual risks, and incident information.
Risk-management activities
Clause 6, normative. A cyclic loop, each activity documented as Input, Requirement, Output, and Assessment criteria, with a PASS verdict when the criteria are met.
Product context
RMA-01Document the intended purpose and reasonably foreseeable use, functions, operational environment, architecture overview, and user description, including any remote data processing solution.
Risk acceptance criteria
RMA-02Define and justify what risk is acceptable for the product context, considering regulatory factors, supply-chain considerations, the nature of known risks, and the state of the art.
Risk assessment
RMA-03 to RMA-06Identify assets and their cybersecurity properties, identify threats, analyse likelihood and impact per threat, then evaluate each risk against the acceptance criteria and justify any accepted residual risk.
Risk treatment
RMA-07Treat every risk that fails the acceptance criteria through avoidance or mitigation, document the decision and its rationale, and re-evaluate the residual risk afterwards.
Risk communication
RMA-08Communicate residual risks transferred to the user in clear, non-technical, accessible language, with the recommended mitigations and the conditions for secure use.
Risk review
RMA-09Review the risk management at planned intervals and on triggers such as product modification, a changed threat landscape, or a newly identified exploitable or actively exploited vulnerability.
Product cybersecurity lifecycle activities
Clause 7, normative. Process-agnostic activities from planning to decommissioning, each with its own normative requirement IDs.
Planning
CLA-01Plan the applicable cybersecurity activities across the full lifecycle, maintain the plan, and track execution.
Requirements
CLA-02Derive product cybersecurity requirements from the context and risk assessment, and keep them under review.
Architecture and design
CLA-03Specify the architecture and controls that fulfil the requirements, holding up under component and third-party integration.
Secure implementation
CLA-04Build in a secure environment, maintain the component list and an SBOM, and prepare the technical documentation and information and instructions to the user.
Verification and validation
CLA-05Verify and validate the controls against the requirements through analysis, scanning, and testing, on a recurring basis.
Secure production and distribution
CLA-06, CLA-07Protect the integrity and authenticity of software and physical products through production and distribution, until placed on the market.
Monitoring and issue management
CLA-08Monitor internal and external sources for vulnerabilities and incidents, and address them without undue delay.
Planning for secure decommissioning
CLA-09Prepare for secure reset or retirement, including how the user removes their data and cybersecurity assets.
Third-party component management
CLA-10Apply due diligence to third-party and open-source components before integration, then verify and monitor them across the lifecycle.
Accessible and inclusive cybersecurity
Annex B, informative
Annex B ties cybersecurity to the European Accessibility Act and the functional performance criteria in EN 301 549. Security features are the front door to a product, so if a person cannot navigate authentication, recovery, configuration, or consent, they can be left exposed or unable to use the product at all.
It asks manufacturers to offer accessible alternatives for each interaction, to avoid single-method authentication that excludes some users, and to communicate with the user in clear, simple language, in the product interface and in the information about the product. Adding accessibility features can also add vulnerabilities, so the annex expects them to be accounted for in the risk assessment.
Evidencing the Annex I Part I requirements
CVD Portal structures the CRA risk assessment, the Annex I Part I control mapping, and the Annex VII technical file so the evidence you produce lines up with the FprEN 40000-1-2 structure. The self-assessment walks the same product context, asset and threat identification, and risk evaluation loop as Clause 6, and the technical file collects the lifecycle activity outputs from Clause 7. When the standard is cited in the Official Journal, that mapping supports presumption of conformity without a rebuild.
Common questions
What is FprEN 40000-1-2?
It is the horizontal harmonised standard being drafted for the Cyber Resilience Act that sets the cybersecurity principles, the product risk-management methodology, and the lifecycle activities behind the CRA Annex I Part I essential requirements. It is tied to the first essential requirement of the CRA, on which the rest of the EN 40000 series builds.
What does the FprEN prefix mean compared with prEN?
FprEN marks a Final Draft submitted to the CEN Formal Vote, one stage beyond the prEN Enquiry draft. Part 1-2 reached Formal Vote in August 2026. Parts 1-1 and 1-3 are still at Enquiry, and part 1-4 is at an earlier phase. A Formal Vote draft is still a draft, so it is not yet a citable EN.
Does applying FprEN 40000-1-2 give me presumption of conformity?
Not yet. Presumption of conformity under CRA Article 27 arrives only once a reference is cited in the Official Journal of the European Union. No CRA harmonised standard is cited yet. Structuring your evidence to the standard now is a low-regret way to be ready when the citation lands.
How is it structured?
Three main clauses. Clause 5 is the informative set of four principles. Clause 6 is the normative risk-management loop, from product context through assessment, treatment, communication, and review. Clause 7 is the normative set of lifecycle activities from planning to decommissioning and third-party components. Clauses 6 and 7 each use a fixed Input, Requirement, Output, and Assessment criteria pattern, with a PASS verdict when the criteria are met.
What does it say about accessibility?
Annex B, an informative annex, ties cybersecurity to the European Accessibility Act and EN 301 549. It sets out how to keep security features usable for people with disabilities, since inaccessible authentication, recovery, or consent flows can lock users out or leave them exposed, and how to communicate with the user in clear, simple language.
Prepare for EN 40000-1-2
Structure your product security evidence to the emerging harmonised standard and export an audit-ready technical file.
Get Started for Free