For machinery, automation, and robotics manufacturers selling into Europe, two EU regulations now share the same calendar. Reporting obligations under the Cyber Resilience Act (CRA) have applied since September 11, 2026. The Machinery Regulation (EU) 2023/1230 is scheduled to apply from January 20, 2027, and the remaining CRA obligations follow on December 11, 2027.
Many organizations have responded with two programs, one for functional safety and one for product security. That split is understandable, and it’s expensive. Both regulations expect a traceable line from risk to requirement to verified control, which means a well-designed CRA and Machinery Regulation traceability model prepares you for both at once.
Why Machinery Makers Run Two Compliance Programs for One Product
The CRA governs products with digital elements, meaning hardware and software with a direct or indirect data connection to a device or network. It sets essential cybersecurity requirements, requires a documented risk assessment, and obligates manufacturers to handle vulnerabilities throughout the support period. Manufacturers must also report actively exploited vulnerabilities and severe incidents through the single reporting platform run by the European Union Agency for Cybersecurity (ENISA), with an early warning due within 24 hours.
The Machinery Regulation text governs machinery safety, and it now addresses cybersecurity directly. Annex III, section 1.1.9 requires protection against corruption, so that connections and remote access can’t lead to hazardous situations and safety-related software and data are protected against accidental or intentional interference. Section 1.2.1 requires control systems to withstand reasonably foreseeable external influences, including malicious attempts by third parties.
A connected robot cell, packaging line, or safety programmable logic controller (PLC) can fall under both regulations. The obligations still arrive through different communities. Product security teams typically work from IEC 62443, while functional safety teams work from ISO 13849-1 and IEC 62061. With different leaders, tools, and risk methods, two programs form almost by default.
What Parallel Compliance Programs Cost the Business
Separate safety and security programs rarely fail at the start. The cost shows up later, at the points where the two disciplines should meet.
- Duplicate risk assessments: Hazard analysis and threat analysis examine the same control architecture, and they often reach different conclusions about which functions need protection.
- Conflicting evidence: Notified bodies and market surveillance authorities may receive two technical files that describe the same safety PLC in different terms.
- Hidden change impact: A firmware patch that closes a vulnerability can alter the behavior of a safety function, and without a link between the records, nobody reviews that effect.
- Delayed market access: Product lines subject to both regulations wait on whichever program is furthest behind.
For leadership, the result is a readiness picture that’s hard to trust. Each program can report progress while the gaps between them stay out of view. We explored this pattern in more depth in The Compliance Evidence Gap.
Where CRA and Machinery Regulation Traceability Chains Meet
The two regulations differ in scope, but their evidence chains share the same structure. Each one begins with a risk assessment and turns identified risks into requirements. Those requirements become design controls, the controls are verified, and the results are recorded in technical documentation that must stay current after the product ships.
That shared structure matters because conformity with one regulation doesn’t automatically carry over to the other. The EU Machinery Regulation grants a presumption of conformity for sections 1.1.9 and 1.2.1 to products certified under a cybersecurity certification scheme adopted under the EU Cybersecurity Act (Regulation (EU) 2019/881). The Cyber Resilience Act doesn’t create an equivalent presumption, so manufacturers of products in scope of both still complete both conformity assessments. Any overlap has to be demonstrated through evidence, and traceability is how you demonstrate it.
| Evidence | Cyber Resilience Act | Machinery Regulation | Shared Traceability Link |
| Risk assessment | Cybersecurity risk assessment based on intended purpose and reasonably foreseeable use (Article 13) | Risk assessment of hazards, including corruption of safety functions (Annex III) | One linked risk model in which threats that can affect a safety function trace to the hazard they could cause |
| Requirements | Essential cybersecurity requirements (Annex I, Part I) | Essential health and safety requirements, including sections 1.1.9 and 1.2.1 (Annex III) | Each requirement written once and mapped to every clause it satisfies |
| Verification | Evidence that cybersecurity requirements are met, including security testing | Evidence that safety functions perform as specified | Test results linked to requirements in both chains |
| Technical documentation | Technical documentation (Annex VII) | Technical documentation (Annex IV) | Documentation produced from the same traced engineering data |
| Post-market obligations | Vulnerability handling (Annex I, Part II) and reporting (Article 14) | Assessment of whether a change is a substantial modification | Vulnerability and change records linked to affected requirements, safety functions, and product versions |
Table 1: Shared evidence chain across the CRA and Machinery Regulation
The Safety and Security Handoff
The most important link in the chain is the one between disciplines. When a threat scenario could corrupt a safety function, that relationship needs to be traceable in both directions. A safety engineer should be able to see which security controls protect a performance level (PL) or safety integrity level (SIL) claim. A security engineer should be able to see which safety functions depend on a given control. That bidirectional link is the evidence both assessments look for.
A shared compliance evidence chain is a single traceable structure that links risks, requirements, design controls, verification results, and technical documentation, so one body of evidence can support conformity assessments under more than one regulation.
A Practical Approach to Preparing for Both Regulations at Once
Preparing for both regulations together is largely an organizational decision, and a traceability model is what makes it hold up under schedule pressure. These six practices give engineering leaders a starting structure.
- One risk model per product line: Safety hazards and cyber threats sit in a single linked structure, with the interfaces between them made explicit.
- Requirements mapped to both regulations: Each requirement is written once and linked to every clause it satisfies, whether that’s a CRA Annex I requirement, a Machinery Regulation section, or an IEC 62443 or ISO 13849-1 clause.
- Verification that counts twice: Test cases link to the requirements they verify, so one test result can support both technical files.
- Change impact reviewed across disciplines: A security patch triggers review of the safety functions it touches, and a safety design change triggers review of the security controls around it.
- Post-market obligations tied to design data: Vulnerability records connect to affected requirements, components, and product versions, so reporting and substantial-modification decisions rest on evidence.
- Readiness measured by producible evidence: Maturity depends on what a team can produce for an assessor on request.
What Leaders Gain From a Connected Evidence Base
Instead of reconciling two status reports, you can view readiness for each product line in one place, including the gaps between safety and security work. Assessments tend to surface fewer conflicting findings because both technical files draw on the same traced data. Change decisions move faster when impact analysis reaches across disciplines, and technical documentation becomes a current view of engineering data rather than a document assembled at the end of a program.
None of this replaces the judgment of safety and security experts. A connected evidence base gives those experts a shared record to work from, and it gives leaders a defensible basis for readiness decisions.
How Jama Connect® Supports CRA and Machinery Regulation Compliance
Jama Connect is a requirements management platform for teams developing complex, regulated products. For industrial machinery manufacturers, several capabilities map directly to the shared evidence chain described above.
- Live Traceability™ and relationship rules: A defined traceability information model controls which item types can link and highlights missing links, so hazards, threats, requirements, and tests follow the same structure on every product line.
- Industrial machinery framework: Jama Software® provides a configurable machinery data model that brings safety, cybersecurity, risk management, and testing into one project structure, with support for ISO 13849-1, IEC 62061, and IEC 62443.
- Trace Score™: Trace Score measures how closely each project follows its traceability model, which shows leaders where gaps exist before an assessment does.
- Impact analysis and baselines: Teams can see every item a change affects across disciplines and capture versioned baselines of requirements and documentation for each release.
- Reviews and electronic signatures: Risk assessments, requirements, and test plans move through formal reviews with recorded approvals.
- Jama Connect Interchange™ with Jira: Development and security teams keep working in Jira while status and comments synchronize with linked items in Jama Connect. A vulnerability ticket stays connected to the requirement and product version it affects.
- Jama Connect Interchange with Excel Functions: Administrators maintain calculation logic in an Excel template, and Jama Connect Interchange applies those formulas to fields in Jama Connect. Teams that already calculate performance level determinations or threat risk ratings in Excel can keep that logic while the results stay traceable.
For a closer look at how these capabilities apply to the CRA, see our CRA webinar recap and our overview of cybersecurity risk management in regulated markets.
Prepare for CRA and the EU Machinery Regulation with Jama Connect
Now is the time to make sure your safety, cybersecurity, requirements, and verification evidence are ready for assessment.
Jama Connect helps engineering teams establish end-to-end traceability across risks, requirements, controls, tests, and changes, giving teams a more defensible evidence base for both regulations.
See how Jama Connect can help you prepare for CRA and EU Machinery Regulation compliance.
Frequently Asked Questions
Does Machinery Regulation Compliance Cover CRA Obligations for the Same Product?
No. The two regulations have separate essential requirements and separate conformity assessments, and a machine with digital elements that falls in scope of both must satisfy both. Shared evidence can support both assessments, but the manufacturer still has to show how each requirement is met under each regulation.
When Do CRA and Machinery Regulation Requirements Take Effect?
CRA reporting obligations for actively exploited vulnerabilities and severe incidents have applied since September 11, 2026. The Machinery Regulation is scheduled to apply from January 20, 2027, and the remaining CRA obligations, including essential cybersecurity requirements and conformity assessment, apply from December 11, 2027. Industry associations have asked the European Commission to align the Machinery Regulation’s cybersecurity provisions with the CRA date, so monitor official updates as you plan.
Which Standards Support Both Regulations?
IEC 62443 is the common reference for industrial control system security, ISO 13849-1 and IEC 62061 cover safety-related control systems, and IEC/TS 63074 addresses security aspects of functional safety for machinery. The draft standard prEN 50742 targets protection against corruption under the Machinery Regulation. Until harmonized standards are cited in the Official Journal of the European Union, these documents provide technical direction without creating a presumption of conformity.
Building One Evidence Base for Both Regulations
Guidance and harmonized standards for both regulations will keep arriving, but the core expectation is already clear: show the traceable path from each risk to the control that addresses it, and the evidence that the control works. Organizations that build that path once across safety and security spend less effort reconciling two programs and more effort engineering the product.
