Write the evidence once. Four regimes want most of the same file

Practical guidance, not legal advice. Check the references below against the official texts before you rely on them, and involve counsel or your assessor on anything that touches a conformity route.

A machine builder ships an industrial unit with a radio module into the EU and also sells it in the United States. Depending on the product, four separate cybersecurity regimes can land on that one machine, each with its own deadline, its own conformity route and its own paperwork. Teams meeting this for the first time usually assume that means four projects.

It does not, and the reason is worth understanding properly, because the way people get it wrong runs in both directions. Some teams do the work four times. Others assume one certificate covers the rest, which is the more expensive mistake.

What each regime actually asks for

Read the columns and the pattern is clear enough. The legal framing differs completely. RED is radio equipment. The CRA is products with digital elements. The Machinery Regulation is machine safety. The Cyber Trust Mark is a voluntary US consumer label. What they are asking about underneath is very nearly the same set of engineering facts.

The evidence that shows up in all of them

These are the artefacts that get requested again and again, in slightly different words, by every one of the regimes above.

• A component inventory, usually as an SBOM. The CRA names it explicitly in Annex I Part II. The others need it to answer anything about known vulnerabilities.
• A risk assessment. Every regime here is risk-based, and the official CRA guidance expects manufacturers to demonstrate the overlaps through the risk assessment rather than by assertion.
• Authentication and access control design. Who can reach the device, how they prove who they are, what happens on default credentials.
• The update mechanism. How updates are delivered, how their integrity is verified, and whether the process can be automated.
• Cryptography and data protection. What is encrypted, in transit and at rest, and with what.
• Logging. What the product records, and whether tampering would leave a trace.
• The vulnerability handling process and the disclosure policy, with a contact address someone reads.
• The support period. How long you will keep issuing security updates, stated in writing.

A team that has answered those eight things once, properly, and written the answers down in a form that can be cited, has done most of the substantive work for all four regimes. That is the reuse, and it is real.

What does not transfer

This is the half that gets oversold, so it is worth being blunt about it.

There is no automatic presumption of conformity between these regimes. The European Commission's own CRA guidance puts it carefully: compliance with the essential cybersecurity requirements of the CRA "could facilitate the compliance" with the overlapping requirements of the Machinery Regulation. Facilitate, not satisfy. The same guidance is explicit that manufacturers have to demonstrate the synergies through their risk assessment, and that both conformity assessment procedures still have to be followed.

• Certificates do not transfer. An EN 18031 assessment result is not a CRA conformity assessment.
• Conformity assessments do not merge. You run the CRA route and the Machinery Regulation route separately, even where the underlying evidence is identical.
• Declarations do not merge. Each regime has its own declaration of conformity with its own required content.
• Scope does not transfer. A product can be in scope for one and out of scope for another, and the RED requirements only apply to radio equipment in the first place.

The practical test: if an assessor asks "how do you know this product does not ship with a default password", the answer and its evidence are the same in every regime. If an assessor asks "show me your conformity assessment", the answer is different in every regime. Reuse the first. Never assume the second.

What the CRA does not cover, and the others do not either

One asymmetry is worth flagging because it catches people. Annex I Part II of the CRA, the vulnerability-handling half, has no real equivalent in the RED work and only a partial one in the Machinery Regulation's lifecycle expectations. A product can hold a clean EN 18031 assessment and still have nothing in place for a coordinated disclosure policy, an SBOM that is maintained rather than generated once, or the Article 14 reporting clock that starts on 11 September 2026.

The reuse runs strongly in the direction of product properties. It runs weakly, or not at all, in the direction of process. Plan accordingly.

How to actually get the benefit

1. Capture the eight evidence items above once, in a structured form, with a citation for each answer rather than a paragraph of prose.
2. Tag each answer with the regimes it serves, so that when the Machinery Regulation work starts you are not re-interviewing the same engineer.
3. Do the risk assessment once and reference it from each file. The official CRA guidance expects the risk assessment to be where you demonstrate the overlaps, so a single well-argued one is worth more than four thin ones.
4. Keep the conformity assessments separate and do not let anyone shortcut them, however similar the inputs look.
5. Watch the calendar independently. The CRA reporting duty starts before the Machinery Regulation applies, and neither waits for the other.

Where Vandorisk sits today

Being straight about this: Vandorisk builds the CRA technical file and the EU Declaration of Conformity from a structured evidence capture. It does not currently produce a RED file, a Machinery Regulation file or a Cyber Trust Mark submission, and we would rather say so than imply otherwise.

What the capture does give you is the eight items above, answered, dated and citable, in one place instead of scattered across a shared drive. That is the input your RED assessor asks for, the input the Machinery Regulation risk assessment needs for Annex III 1.1.9 and 1.2.1, and the input that maps onto the NIST IR 8425 baseline behind the Cyber Trust Mark. Direct output for those regimes is on the roadmap. Today the reuse is manual, and the value is that the answers exist and can be found.

The FCC programme is the one to watch rather than plan around. UL Solutions withdrew as lead administrator in December 2025 and the FCC named the ioXt Alliance in April 2026, so the timetable for actual labels is still moving. The underlying NIST IR 8425 criteria have been stable throughout, which is why the evidence is worth capturing now regardless of when the label arrives.

The arithmetic

Eight evidence items, answered once. Four regimes that each want most of them. Four conformity assessments that still have to be run separately, and one risk assessment that can carry the argument across all of them if it is written to.

The saving is in the interviews you do not repeat, not in the assessments you skip.