CRA for Startups: Lean Compliance With One Engineer

You are shipping a connected product with a small team, and the CRA is going to cover it. Its main duties apply from 11 December 2027, with vulnerability reporting from 11 September 2026, so this is a build-it-in-now problem, not a someday one. Two things catch startups: the multi-year security-support duty you take on the moment you place the product on the EU market, and doing all of it without a dedicated security hire.

This guide is for founders and early engineers who need to be CRA-compliant without overspending or over-building. It covers what you can safely skip, what you cannot, and how one person can own the whole thing.

Does CRA even apply to your startup?

Run four quick checks. The CRA covers products with digital elements that connect to a network or another device and are made available on the EU market in the course of a commercial activity.

If your product is in scope, the next question is which category it lands in. That decides whether you self-assess or need a Notified Body. Confirm it with the product classification guide before you spend a day on anything else.

Your one structural advantage: self-assessment

The single biggest cost saver for a startup is that a product outside the Important and Critical categories is a Default product. For those, the CRA lets you self-assess: you do the conformity work yourself, sign the EU Declaration of Conformity, and apply the CE marking. No external body, no per-product fee. The mechanics of each route live in the conformity assessment guide. The startup point is not to pay for third-party assessment you do not need.

The reliefs the CRA built for startups

The CRA carries support measures written specifically for microenterprises, small and medium-sized enterprises, and start-ups. Whether the reliefs apply depends on your size, using the standard EU definition: a microenterprise has fewer than 10 staff and turnover or balance sheet at or below EUR 2 million, and a small enterprise has fewer than 50 staff and turnover or balance sheet at or below EUR 10 million.

Four reliefs a startup can actually use:

• Simplified documentation: microenterprises and small enterprises may file the technical documentation in a simplified format that the Commission specifies, and Notified Bodies must accept that form.
• Reduced conformity fees: where your product does need a Notified Body, the specific needs of SMEs, including start-ups, must be taken into account and the fees reduced proportionately.
• Regulatory sandboxes: Member States may set up controlled environments where you develop and test an innovative product against the CRA before you place it on the market, with access for start-ups facilitated.
• Direct support: where appropriate, Member States run awareness and training activities and a dedicated advice channel for smaller companies, and the Commission signposts available financial support.

Getting compliant with one engineer

You do not need a security team. You need one accountable owner and a short list of things that run automatically. That person maintains the technical file, triages incoming vulnerability reports, and signs the Declaration of Conformity. One person can hold the role, but be honest that the ongoing vulnerability handling, update delivery, and documentation are real engineering work. The CRA compliance cost guide models the effort and budget for a small team so you can plan the headcount properly.

Three things are worth automating first. Each is a solved problem with free tooling, and together they clear your most visible early obligations. They are a starting point, not the whole picture.

• Generate an SBOM in CI: the CRA requires a software bill of materials covering at least your top-level dependencies, and open-source tools such as Syft and Trivy produce one on every build. Full toolchain in the SBOM generation guide.
• Monitor for vulnerabilities: scan your dependencies on every build and act on findings based on risk before they reach customers. The CRA cares that you triage and fix, not which scanner you run.
• Publish a security contact: a security.txt file and a working security address give researchers a way to report. The security.txt setup guide has a ready template.

Those three are early automation wins, not the whole job. Secure design, risk assessment, update delivery, and the product controls sit alongside them. Your technical documentation grows with the product rather than in a pre-launch scramble, so keep architecture and security notes as you go. The required contents are in the technical documentation guide.

Your vulnerability-handling process needs to be live before the reporting obligations start on 11 September 2026. From that date, an actively exploited vulnerability or a severe incident starts a tight clock through the ENISA single reporting platform: an early warning within 24 hours, then a fuller notification within 72 hours. The final report differs by track. For an actively exploited vulnerability it is due within 14 days of a corrective or mitigating measure being available. For a severe incident it is due within one month of the 72-hour notification. You must also inform affected users. The mechanics are in the vulnerability reporting guide.

You can ship fast without re-certifying every release

Iterating quickly does not mean re-running conformity assessment every sprint. You revisit conformity only after a substantial modification, which is a change after launch that affects the product's compliance with the essential requirements, or changes the intended purpose it was assessed for. A security update that only reduces cybersecurity risk without changing the intended purpose is not a substantial modification, and a minor change such as adding a UI language generally is not either. A feature update that broadens the attack surface or changes what the product does can be. So routine patches and small updates ship without re-assessment, and you reassess when a change genuinely alters what the product is or its risk profile.

If you build on or steward open source

Two open-source facts matter for a startup. First, free and open-source software is only in scope when it is supplied in the course of a commercial activity. Software its maintainers do not monetise is generally not a commercial activity, but monetisation is broader than charging for the code, so weigh paid support and similar arrangements. Contributing source code to a project that is not under your responsibility does not make the CRA apply to you. Monetising open source, or shipping it inside a product you sell, brings that product into scope as normal.

Second, the CRA creates a lighter role called an open-source software steward for an organisation, other than a manufacturer, that sustains the development of open-source software intended for commercial use. A steward's duties centre on a documented cybersecurity policy and cooperation with authorities. Vulnerability reporting applies to the extent the steward is involved in the product's development, and severe-incident reporting and user notification apply where an incident affects the systems the steward provides for that development. These duties are lighter than the full manufacturer obligation set. If your startup both stewards a project and sells a product, be clear which hat you wear for which activity, because the obligations differ.

The five-year support duty is a business-model problem

This is the part of the CRA that a startup cannot tool its way out of. The support period must be at least five years, and where the product is expected to be in use for less than five years, it matches that shorter expected use. During that period you handle vulnerabilities based on risk, remediate them without delay, and deliver the updates to customers.

For an early-stage company that is a real commitment, not a checkbox:

• The duty follows the product: it attaches when you first place the product on the EU market, and a later pivot does not end it for units already placed.
• It has to be priced in: if your margin does not carry the support period, the price is wrong. Model support cost into unit economics before launch, and expect it to taper as the codebase stabilises.
• Plan for ten years, not five: each security update you issue must stay available for at least 10 years after release, or for the rest of the support period, whichever is longer.
• Publish the end date: you must show the support-period end date, at least the month and year, at the time of purchase. Set it deliberately, because customers and buyers will read it.

You can make the commitment more survivable, but mind what actually discharges it:

• Choose stable dependencies: every fast-moving library you pull in is years of maintenance you signed up for. Prefer boring, well-supported components.
• Version deliberately: define product generations and plan how support hands off between them, so you are not maintaining an unbounded set of live versions.
• Mitigations are not a discharge: a written support-transfer to an acquirer, an escrow arrangement, or open-sourcing the security-critical components can keep fixes flowing, but none of them by itself removes your obligation.

If you cease operations and can no longer comply, you must inform the market surveillance authorities and, as far as possible, your users before the cessation takes effect. What happens to the residual duty once the company no longer exists is not cleanly settled and depends on jurisdiction. Plan the wind-down path now, while you still can, and document it in the technical file.

Turn compliance into sales and funding

For a startup, CRA work can do double duty: it opens EU market access, and it gives you evidence to hand an enterprise buyer or an investor.

Build the due-diligence pack once. EU procurement teams may ask, during vendor onboarding, for a current SBOM, a signed Declaration of Conformity, and a documented vulnerability disclosure process with a response timeline. These are strong evidence rather than proof of full compliance, since readiness ultimately rests on meeting every essential requirement. But having them assembled in one place saves you scrambling to collect the evidence later, and it is the same pack an investor's technical diligence may ask to see.

Investors care that you can legally ship. Breaching the essential requirements or the core manufacturer duties carries administrative fines of up to EUR 15 million or 2.5% of total worldwide annual turnover, whichever is higher. More practically, a product placed on the EU market from 11 December 2027 must meet the CRA to be sold there. Framing compliance as market access and de-risked EU entry lands better with a board than framing it as a cost.

Public programmes can fund part of the work. EU instruments such as Horizon Europe, the Digital Europe Programme, and the EIC Accelerator support cybersecurity and secure-product development, and national programmes add more. Amounts and eligibility vary, so check your national digital innovation hub for what is open. Frame the application around building trustworthy, secure digital products rather than around ticking a regulatory box.

If security certifications come up in sales, know where the CRA sits relative to them. The overlap with an ISMS is covered in the CRA vs ISO 27001 guide, and consumer-IoT teams should read the EN 303 645 guide.

Common startup mistakes

• "We'll deal with security after the raise": on a runway, retrofitting security burns the cash you just raised. Build the basics in from the first sprint.
• "We priced the product without the support duty": multi-year security maintenance has to sit inside your unit economics. If it does not, the price is wrong.
• "Our compliance owner left and no one picked it up": if one person holds the technical file and the reporting process, their departure is a compliance gap. Write down who owns it.
• "The acquirer will just take on the duty": a deal can assign the support work, but it does not by itself lift the statutory duty from you. Handle it explicitly in the terms, and assume nothing.
• "We'll bolt on CRA when we expand to the EU": if EU users can already reach your product, you are already supplying the EU market, and retrofitting compliance later is a rebuild. Design for the 2027 duties from the start.
• "We're too early-stage to be in scope": being a startup earns you reliefs, not an exemption. The duty attaches at first placement whatever your stage.