Picture a request from a market surveillance authority in 2031. A vulnerability in one of your products has made the news, and the authority wants to see the risk assessment, the support period decision and the record of how you handled the report. The people answering will be your engineers, not whoever helped you in 2026.
The CRA makes that scenario normal. The manufacturer carries the obligations in Article 13 and the reporting duty in Article 14, draws up the technical documentation (Article 31) and signs the EU declaration of conformity (Article 28). Vulnerability handling runs for the support period, which is at least five years for most products (Article 13(8)), and the technical file has to be kept for at least ten years, or for the support period if that is longer (Article 13(13)).
Measured against that timeline, the three usual ways of organising the work look quite different.
Option 1: a consultant
A good consultant reads your situation quickly, knows where assessors look and can write a convincing document. For a second opinion on an unusual product, or a review before an audit, that is money well spent.
As the main vehicle, it has two problems. The meter runs by the day, and it starts again with every new product and every update cycle. And when the engagement ends, the reasoning behind the documents tends to leave with the consultant. Your team inherits a file it did not write and has to defend decisions it did not make.
Option 2: a compliance platform
Compliance platforms sell automation: SBOM generation, vulnerability scanning, deadline tracking and a document store, by subscription. For a software team that ships every week, the automation is real.
What you give in return is your most sensitive material. Source code or build artefacts, SBOMs, unpatched vulnerabilities and incident details go to a provider that your security team and procurement will want to vet first. The fee recurs for as long as you sell: €300 a month is €18,000 over a five-year support period, and more if the price is per product. Your records sit in the provider's format, and a ten-year retention period outlasts most contracts. The scanning part is not exclusive either. Free open-source tools generate SBOMs and match them against vulnerability databases inside the build pipeline you already run.
Option 3: a template kit
A template kit gives you the documents and workbooks the regulation implies, laid out article by article, with guidance and filled-in examples. Your team completes them on your own systems.
That sounds like more work, and in the first weeks it is. It is also the only option where the knowledge ends up in the right place. An engineer who has worked through the risk assessment and the support period record knows why the product is rated the way it is, and can explain it to an authority five years later.
The rest follows from owning the files:
- Word, Excel and PDF need no licence and will still open in 2036.
- Nothing leaves your network, so there is no vendor review.
- One payment covers every product you add later.
- Whatever scanner you use, open-source or commercial, its output feeds the kit's SBOM and vulnerability procedures.
A kit also fits every product class. Every conformity assessment route is built on the technical file. Where a notified body is involved (Class II and critical products, and Class I when harmonised standards, common specifications or a certification scheme are not applied in full, Article 32(2)), the notified body assesses that same file. The kit is how you build it.
What a kit will not do is decide for you. It shows what has to be decided and how to record it. That is what authorities expect to find: a manufacturer that understands the risks of its own product.
Side by side
| Consultant | Platform | Template kit | |
|---|---|---|---|
| Who holds the knowledge afterwards | Largely the consultant | The provider's system | Your team |
| Cost model | Day rate, repeated for every product and update | Yearly subscription, often per product or user | One payment |
| Cost over a five-year support period | Grows with every engagement | Five or more years of fees | Paid once |
| Where your product data lives | Shared with an outside party | In the provider's cloud | On your own systems |
| Format of your technical file | Whatever is delivered | The provider's format; export terms vary | Word, Excel and PDF that you control |
| When the contract ends | The knowledge leaves | Export terms decide what you keep | Nothing changes |
| Notified body routes | Supported | Supported | Supported: the kit structures the file the notified body assesses |
| Time to start | After contract and onboarding | After vendor review and setup | Today |
| Code scanning and SBOM generation | Advice on tools | Included | Your existing tools or free open-source tools |
The setup most manufacturers end up with
In practice the strongest setup takes the best of all three without paying for all three. The kit carries the structure, the decisions and the technical file. Your existing or open-source scanners do the automation and feed their output into it. If you want an outside view, book an expert for a day or two to review the finished file before the audit. That costs a fraction of a consulting engagement, and nothing you depend on sits outside your company.
Four questions to ask about any option
- Who in our company will understand this file in five years?
- What does it cost over the whole support period, not just the first year?
- Where does our product data go, and what do we keep if the contract ends?
- Can we hand the result to an authority or a notified body as it is?
This article explains Regulation (EU) 2024/2847 in plain words. It is not legal advice.