Saša Tomić

Cyber Resilience Act readiness

The Cyber Resilience Act, usually shortened to CRA, is an EU cybersecurity law for hardware and software products made available on the EU market.

It applies to what the law calls products with digital elements: hardware or software whose intended or reasonably foreseeable use includes a direct or indirect connection to another device or network.

Examples include industrial sensors, connected machinery, smart-home devices, cameras, desktop and mobile applications, operating systems, commercial developer tools, firmware, and hardware or software components sold separately.

The two dates that matter

The CRA has two important application dates.

11 September 2026
Manufacturers started having to report certain actively exploited vulnerabilities and severe security incidents.

11 December 2027
The main CRA product requirements start applying. New covered products placed on the EU market from this date must meet the applicable security, vulnerability-handling, documentation, conformity-assessment and CE-marking requirements.

The distinction is important:

From 11 September 2026 to 10 December 2027

If you are the manufacturer of a covered product already on the EU market, the CRA’s reporting rules apply, but the full CRA product-compliance package is not yet generally required.

If a reportable security problem occurs, you may need to:

You still do not have to submit your complete SBOM, source code, technical documentation or full CRA compliance file.

From 11 December 2027

A new covered product must meet the full applicable CRA requirements before it is placed on the EU market.

That includes the applicable:

The reporting rules continue as well.

So after 11 December 2027 there are two separate layers:

  1. The product must already be CRA-compliant before market entry.
  2. If a reportable security event later occurs, the 24-hour, 72-hour and final-report process still applies.

First: are you selling into the EU?

The CRA regulates products made available on the EU market.

Switzerland is not part of the EU. Selling a product only in Switzerland therefore does not, by itself, make that product subject to the CRA.

For example:

A Swiss retailer buys a connected thermostat and resells it only to Swiss customers.
That Swiss resale does not put the product on the EU market.

The same business supplies covered products to customers in Germany, France or another EU country.
The EU market is now involved, so the CRA can apply.

The same principle applies to software. A Swiss software company does not become subject to the CRA simply because somebody in the EU could theoretically use its website. If it actually makes a covered software product available to the EU market, the CRA can apply.

Online sales

Operating a website from Switzerland does not avoid EU product rules.

A product offered online can be considered made available on the EU market when the offer is targeted at EU users.

Signs of targeting can include:

Simply having a website that somebody in the EU can access is not enough on its own.

Is your product covered?

A product generally falls within the CRA when all of these are true:

  1. it is hardware, software, or a hardware or software component
  2. it is made available on the EU market as part of commercial activity
  3. its intended or reasonably foreseeable use includes a direct or indirect connection to another device or network
  4. it is not covered by a specific CRA exclusion

Commercial activity means supplying the product as part of business activity. Payment is not required: a product supplied for free can still be commercial.

Direct and indirect connections

A direct connection can include technologies such as Ethernet, USB, Wi-Fi, Bluetooth, NFC or another data connection.

An indirect connection means the product communicates as part of a larger connected system even if it does not itself connect directly to the internet.

For example, an industrial sensor connected to a controller through an industrial data bus can still be part of a connected system.

“It has no Wi-Fi” therefore does not automatically mean “the CRA does not apply.”

Common examples in scope

Examples include:

Firmware is software embedded inside hardware, for example the software running inside a sensor, controller or appliance.

Products without a qualifying digital connection

The CRA does not regulate every object that contains electronics.

It would not normally apply to:

The important question is not simply whether the product contains a chip.

Standalone SaaS

SaaS, or Software as a Service, is software mainly accessed remotely over the internet rather than supplied as a standalone software product.

Standalone SaaS is generally not itself a product with digital elements under the CRA.

There is an important exception for remote data processing that forms part of a covered product.

Remote data processing means software operated remotely by or for the manufacturer where the product would lose one of its functions without that remote processing.

For example, if a connected building-control device depends on the manufacturer’s cloud service to perform one of its functions, that cloud functionality can form part of the CRA product.

A completely independent web service does not become a CRA product merely because it runs in the cloud.

Websites

A normal website is not itself a product with digital elements merely because users can access it.

It can become relevant when it provides remote processing required for a covered product to function.

Open-source software

Free and open-source software supplied outside commercial activity receives special treatment under the CRA.

Open-source software is software whose source code is available under a licence that permits people to use, study, modify and redistribute it.

“Open source” does not automatically mean “outside the CRA.”

If a business commercialises software or places it on the market under its own responsibility, CRA obligations can still arise.

The CRA also defines an open-source software steward: a legal organisation that provides sustained support for specific open-source products intended for commercial use and helps ensure their continued viability.

Open-source software stewards have a separate set of obligations, with their CRA reporting obligations starting on 11 December 2027.

Products covered by other EU legislation

Some products are excluded because other EU legislation already regulates them.

Important examples include certain:

The exclusion depends on whether the particular product is actually covered by the relevant EU legislation.

A device used in a hospital is not automatically a medical device. A component used in an aircraft is not automatically excluded simply because it eventually goes into an aircraft.

Manufacturer, importer or distributor?

The CRA gives different responsibilities to manufacturers, importers and distributors.

Manufacturer

A manufacturer is the person or company that develops or manufactures a product, or has it developed or manufactured, and markets it under its own name or trademark.

You do not need to own a factory.

For example, a Swiss company designs a connected industrial monitoring device, pays another company to manufacture the hardware, and sells the finished product under the Swiss company’s brand.

The Swiss company is the manufacturer.

If the product is made available on the EU market, the Swiss company has the CRA manufacturer obligations even though it is based in Switzerland.

Importer

An importer is a person or company established in the EU that places on the EU market a product carrying the name or trademark of a person or company established outside the EU.

For example:

A Swiss manufacturer produces a connected industrial sensor.

A German company first places that sensor on the EU market under the Swiss manufacturer’s brand.

The Swiss company is the manufacturer. The German company is the importer.

From 11 December 2027, the importer must check that the required CRA work has been completed before placing the product on the EU market, including that:

A Swiss company does not itself become a CRA importer merely because it ships a product from Switzerland. The CRA definition of importer requires the importer to be established in the EU.

A Swiss company can, for example, use an EU subsidiary as the importer.

Distributor

A distributor is another company in the supply chain that makes a covered product available on the EU market without being the manufacturer or importer and without changing the product’s properties.

This often covers resellers.

For example, a reseller buys a connected building-control device that has already entered the EU market and resells it unchanged under the original manufacturer’s brand.

From 11 December 2027, distributors must exercise due care and check required information such as:

If a distributor knows or has reason to believe that the product does not comply with the CRA, it must not continue making the product available until the problem is corrected.

If a distributor becomes aware of a vulnerability, it must inform the manufacturer without undue delay.

If the product presents a significant cybersecurity risk, meaning a cybersecurity risk serious enough to require rapid action by authorities, the distributor must also inform the relevant EU market-surveillance authorities.

A market-surveillance authority is a national authority responsible for checking whether products sold on its market comply with applicable EU rules.

What if a Swiss reseller sells directly into the EU?

The exact role depends on how the supply chain is structured.

If an EU-established company first places a product carrying a non-EU manufacturer’s brand on the EU market, that EU company is normally the importer.

If a reseller later supplies an already-imported product unchanged, it can be a distributor.

Direct sales from Switzerland into the EU need to be assessed based on the actual supply chain rather than assuming that every reseller is automatically an importer or distributor.

When does a reseller become the manufacturer?

An importer or distributor is treated as the manufacturer if it:

For example, buying another company’s connected product, putting your own brand on it and selling it as your product can make you the manufacturer for CRA purposes.

The same applies if you substantially modify an existing product.

Simply reselling an unchanged product under the original manufacturer’s brand does not automatically make you the manufacturer.

Which deadline applies to you?

There are three common situations.

A. Your product is already on the EU market today

If you are the manufacturer, you do not need to make every existing product fully CRA-compliant today.

But the Article 14 reporting rules have applied since 11 September 2026.

If a reportable security event occurs, the reporting process described below applies.

The main CRA product requirements do not generally apply retroactively to individual products already placed on the EU market before 11 December 2027.

The main exception is a substantial modification made after 11 December 2027.

B. You will first place the product on the EU market before 11 December 2027

Suppose a Swiss company develops a connected industrial vibration sensor for monitoring machinery and supplies 4,000 units to a German importer in June 2027.

For those units:

Now suppose the Swiss manufacturer continues producing the same sensor.

4,000 units placed on the EU market in June 2027
Those individual units fall under the transitional rules.

Another 2,000 newly produced units first placed on the EU market in January 2028
Those units must meet the applicable full CRA requirements before market entry.

Launching the product model before December 2027 does not permanently exempt later units of the same model.

C. Your product will first enter the EU market after 11 December 2027

The product must meet the full applicable CRA requirements before it is placed on the EU market.

For example:

First EU market entry: 1 April 2028
Compliance deadline: before the product is placed on the EU market on 1 April 2028

You do not have to finish the work by 11 December 2027 merely because the CRA becomes fully applicable on that date.

But you cannot place the product on the EU market first and complete CRA compliance afterwards.

What does “placed on the EU market” mean?

A product is placed on the market when that individual product is made available on the EU market for the first time as part of commercial activity.

This can happen when a manufacturer or importer first supplies a completed product to:

The distinction applies to individual products, not simply to a product-model name.

That is why the same model can have:

Products already placed on the EU market do not become newly placed simply because they remain in a distributor’s warehouse or are later sold to the final customer.

What is a substantial modification?

A product placed on the EU market before 11 December 2027 can become subject to the main CRA requirements if it undergoes a substantial modification after that date.

A substantial modification is a change that was not foreseen in the original cybersecurity risk assessment and that affects the product’s cybersecurity compliance, changes its intended purpose, or increases or changes the cybersecurity risk in a relevant way.

A normal security update intended only to reduce cybersecurity risk does not generally count as a substantial modification.

Minor changes such as visual changes or additional interface languages also do not normally amount to substantial modifications.

What must be reported from 11 September 2026?

Manufacturers must report when they become aware of either:

  1. an actively exploited vulnerability, or
  2. a severe security incident affecting the product

A report means notifying the relevant EU cybersecurity authorities through the CRA Single Reporting Platform.

It does not mean sending your entire SBOM, source code, technical documentation or complete CRA compliance file.

Actively exploited vulnerability

A vulnerability is a weakness that can be exploited to compromise a product’s security.

An actively exploited vulnerability is one for which there is reliable evidence that a malicious actor has actually exploited it without the system owner’s permission.

For example:

A security researcher discovers a vulnerability during authorised testing, with no evidence of malicious exploitation.
Not automatically reportable.

A vulnerability scanner finds a vulnerable dependency.
Not automatically reportable.

Your team discovers a serious zero-day, but there is no evidence attackers have used it.
Not automatically reportable under the active-exploitation rule.

A zero-day is a vulnerability that was previously unknown or for which a security fix is not yet available.

There is reliable evidence that attackers are exploiting the vulnerability against real systems.
The reporting obligation applies.

The reporting clock starts when the manufacturer becomes aware of the active exploitation.

Severe security incident

A security incident is an event affecting the security of the product.

An incident is severe under the CRA when it has, or can have, a serious effect on the product’s ability to protect important data or functions.

This includes effects on:

An incident can also be severe if it has led, or can lead, to malicious software being introduced or executed in the product or in a user’s systems.

What happens when reporting is required?

Once the manufacturer becomes aware of a reportable event:

Within 24 hours
Submit an early warning.

Within 72 hours
Submit a fuller notification with the information available about the product, vulnerability or incident, exploitation, initial assessment, measures already taken, and measures users can take.

Reports are submitted through the CRA Single Reporting Platform.

The platform is operated for CRA reporting by ENISA, the European Union Agency for Cybersecurity, together with the relevant national cybersecurity authorities.

Affected users

The manufacturer must also inform affected users of the actively exploited vulnerability or severe incident and, where necessary, tell them what they can do to reduce the risk.

That can include:

Is there a deadline for the fix itself?

For an actively exploited vulnerability, Article 14 does not set a fixed number of days in which a corrective or mitigating measure must become available.

A corrective or mitigating measure is something that fixes the vulnerability or reduces its risk, such as a patch, configuration change or workaround.

Once such a measure is available, the manufacturer must submit the final vulnerability report no later than 14 days later.

That final report includes information such as:

For a severe security incident, the final report follows a different clock: it is generally due within one month after the 72-hour incident notification.

From 11 December 2027, the full CRA vulnerability-handling requirements also apply to covered new products. Those requirements say manufacturers must address and remediate vulnerabilities without delay, including by providing security updates where appropriate.

So the clean distinction is:

Before 11 December 2027:
Article 14 gives you the reporting deadlines. It does not yet require the full CRA SBOM, technical file and vulnerability-handling system simply because the product is on the market.

From 11 December 2027:
The full vulnerability-handling requirements apply in addition to reporting. A manufacturer cannot treat the absence of a fixed “seven-day patch deadline” as permission to leave a known vulnerability unresolved indefinitely.

What changes on 11 December 2027?

From this date, new covered products placed on the EU market must meet the applicable full CRA requirements before market entry.

For manufacturers, that includes the following areas.

Cybersecurity risk assessment

A cybersecurity risk assessment is a documented analysis of what can go wrong, how likely it is, what damage it could cause, and which security measures are needed.

It considers factors such as:

The assessment determines which CRA security requirements apply and how the manufacturer addresses them.

Product-security requirements

The main technical requirements are listed in Annex I of the CRA.

An annex is a section attached to the law containing detailed requirements.

Depending on the product and its risks, the manufacturer must address requirements such as:

Vulnerability handling

The manufacturer also needs a process for handling vulnerabilities throughout the product’s support period.

This includes:

A coordinated vulnerability-disclosure process tells researchers and other people how to report security weaknesses safely and how the manufacturer handles those reports.

Support period

The manufacturer must define a support period: the period during which it commits to handling vulnerabilities in the product.

As a general rule, this is at least five years, unless the product is reasonably expected to be used for a shorter period. Products expected to remain in use for substantially longer may require a longer support period.

The end date of that support period has to be communicated to users.

SBOM

An SBOM, or Software Bill of Materials, is a machine-readable list of software components contained in a product.

Think of it as an ingredient list for software.

If the product contains an operating system, external libraries and internal software packages, the SBOM records the relevant components.

The CRA requires manufacturers to identify and document product components and vulnerabilities, including an SBOM covering at least the product’s top-level dependencies.

A dependency is another software component that the product relies on.

A top-level dependency is one directly included by the product rather than pulled in indirectly by another dependency.

The SBOM is part of the broader CRA vulnerability-handling and technical-evidence system.

It is not something that must automatically be attached to every 24-hour or 72-hour security report.

Technical documentation

The manufacturer must prepare technical documentation showing what the product is, what its cybersecurity risks are, and how it meets the applicable CRA requirements.

It can include:

This is what I refer to on this page as the technical file.

Conformity assessment

A conformity assessment is the process used to verify that the product meets the applicable CRA requirements.

Not every product requires an external audit.

For many ordinary products, the manufacturer can use an internal conformity-assessment procedure.

Certain products classified as important or critical under the CRA can require stricter procedures, including involvement of a notified body.

A notified body is an independent organisation authorised by an EU Member State to perform specified conformity assessments.

The correct assessment route depends on the product category and, for some categories, which recognised standards or certification schemes are used.

EU declaration of conformity

After completing the required conformity assessment, the manufacturer prepares an EU declaration of conformity.

This is the formal document in which the manufacturer declares that the product meets the applicable EU requirements and takes responsibility for that declaration.

CE marking

The CE mark is the CE symbol used on products covered by EU product legislation.

For a CRA-covered product, it indicates that the manufacturer declares that the product complies with the applicable requirements.

CE marking does not necessarily mean that an EU authority personally tested the product.

For many products, the manufacturer can use the permitted internal conformity-assessment procedure. Products requiring stricter assessment involve an independent notified body.

What I build

I am Saša Tomić.

I build the engineering systems behind CRA compliance.

My work is primarily aimed at manufacturers and companies that have taken on manufacturer responsibilities, because that is where most of the engineering work sits.

I can also help importers and distributors build technical processes for checking products, tracking vulnerabilities and maintaining evidence.

The work is split into three stages.

1. Vulnerability reporting

This is the part already relevant to manufacturers today.

Security contact

I add a security.txt file.

security.txt is a standard file published on a website that tells security researchers how to report vulnerabilities.

I connect that reporting channel to the system the engineering team already uses to track work.

Triage

Triage means reviewing a security report and deciding:

I turn those decisions into a repeatable workflow instead of leaving them scattered across email and chat.

Reporting workflow

The system prepares the information needed for:

It also records when important events happened.

That creates an evidence trail: records showing when the team learned about the problem, investigated it, decided whether it was reportable, reported it, mitigated or fixed it, and released the relevant changes.

Dry run

We then simulate a real security event through the entire process:

  1. intake
  2. triage
  3. reporting decision
  4. early warning
  5. fuller notification
  6. mitigation or remediation
  7. user communication
  8. final report
  9. documentation

The goal is to find broken steps before a real 24-hour clock starts.

2. SBOM and vulnerability automation

The next stage is knowing what software is actually inside every product release.

Automatic SBOMs

I connect SBOM generation to the product’s CI system.

CI, or Continuous Integration, is the automated system that builds and tests software as code changes. It can also produce releases and security evidence.

The CI system generates a current SBOM for each relevant release instead of relying on a document somebody generated manually months earlier.

The SBOM can use standard machine-readable formats such as:

Both are established formats for describing software components and software supply chains.

VEX

I can also generate and maintain VEX, or Vulnerability Exploitability eXchange, information.

A scanner may detect a known vulnerability in a software component without knowing whether your product actually uses the vulnerable function.

A VEX statement records the product-specific assessment, for example:

VEX is not itself a general CRA requirement.

It is a practical engineering tool for documenting what a published vulnerability actually means for your product.

Vulnerability monitoring

I connect released components to vulnerability information.

When a relevant vulnerability appears, the system can identify affected releases and open an engineering ticket automatically.

That turns vulnerability information into an engineering process rather than a recurring manual investigation.

3. CRA technical documentation and engineering readiness

Before a product subject to the full CRA rules is placed on the EU market, the manufacturer needs evidence showing why it complies.

I build as much of that evidence as possible from the systems that already produce the software.

This can include:

Secure defaults

Secure by default means the product starts in an appropriately secure configuration rather than requiring customers to discover and enable every important protection themselves.

I review the actual product configuration and help fix defaults that create unnecessary security risk.

Secure updates

The product needs an appropriate way to receive security fixes.

I review or build the update path so the product can verify that an update is authentic before installing it.

Where appropriate, I also test rollback.

Rollback means returning to a previous software version if an update fails.

Rollback itself must be secure: allowing unrestricted rollback to an old vulnerable version can create another security problem.

Conformity-assessment evidence

I prepare the engineering evidence needed for the applicable conformity-assessment route.

For products that can use internal assessment, the evidence needs to support the manufacturer’s own conformity decision.

For products requiring independent assessment, it needs to be organised so the notified body can review it efficiently.

CRA compliance has legal and technical parts.

Legal counsel handles legal interpretation and determines the company’s legal position.

I handle the engineering systems and evidence, then work with legal counsel so the legal documentation describes what the product and engineering systems actually do.

Why me

CRA compliance becomes expensive when every requirement turns into manual work.

Cetome estimates that preparing a first product for CRA compliance can cost around €100,000.

Linux Foundation research found that organisations maintaining private forks, meaning their own modified versions of open-source projects, spend an average of $258,000 in engineering labour per release cycle.

Automation does not remove the legal requirements. It reduces the repeated engineering work required to meet them.

At DFINITY, I automated reproducible builds and the CI and release systems used to deliver new software roughly twice a week through a content delivery network to a production network of more than 1,400 nodes.

A reproducible build is a software build designed so that the same source code and build instructions produce the same result. This makes it easier to verify exactly what software was produced.

A content delivery network, or CDN, is a distributed network of servers used to deliver files reliably.

I led the Mainnet Reliability team responsible for a production network carrying more than $2 billion in assets, and for a period more than $10 billion.

We automated software releases and rollouts and operated the process publicly.

I also worked closely with the production security team on incidents and reliability. No major security incident affected the network while I led the team, and our automation was a key part of handling security incidents quickly and consistently.

My full professional background is available on the about page.

How an engagement works

We sign a non-disclosure agreement, or NDA, by default.

An NDA is a legal agreement requiring confidential information shared during the work to remain confidential.

Work is normally remote and asynchronous, meaning most work does not require everyone to be online or in meetings at the same time.

I work directly in your repository and CI system.

A repository is the system where source code and its change history are stored.

Access follows the principle of least privilege: I receive only the access needed to perform the work rather than broad administrator access.

The automation, documentation and evidence are built in your systems and stay with you after the engagement.

For a typical vulnerability-reporting project:

Week one

Week two

SBOM automation, vulnerability monitoring and technical documentation are scoped separately based on the product and existing engineering environment.

Quick reference

SituationWhat the CRA requires
Swiss company sells a connected product only in SwitzerlandThe CRA does not apply merely because of the Swiss sale
Swiss manufacturer sells its own covered product into the EU todayManufacturer reporting obligations apply
Swiss reseller sells an unchanged third-party product only in SwitzerlandNo CRA obligation merely from that resale
Reseller makes an already-imported covered product available in the EU unchanged under the original brandDistributor obligations can apply
EU company first places a Swiss manufacturer’s product on the EU marketThe EU company can be the importer; the Swiss company remains the manufacturer
Reseller puts its own name or trademark on the productIt can become the manufacturer for CRA purposes
Reseller substantially modifies the productIt can become the manufacturer for CRA purposes
Product has no qualifying digital connectionOutside the CRA
Standalone SaaS with no qualifying product connectionGenerally outside the CRA
Covered product already on the EU market before 11 December 2027Article 14 manufacturer reporting applies; the full CRA product package does not generally apply retroactively
Covered product first placed on the EU market between now and 10 December 2027Reporting applies; full CRA product documentation and conformity requirements do not yet generally apply to that product
New covered product first placed on the EU market from 11 December 2027Full applicable CRA requirements must be met before market entry, and reporting continues after launch
Actively exploited vulnerability before 11 December 202724-hour warning, 72-hour notification, affected-user communication, then final report within 14 days after a corrective or mitigating measure becomes available
Actively exploited vulnerability from 11 December 2027Same reporting process, plus the full CRA vulnerability-handling duty to address and remediate vulnerabilities without delay
Severe security incident24-hour warning, 72-hour notification and final report within one month after the 72-hour notification

Next step

Message me on LinkedIn with:

I will send you a written CRA readiness assessment within two days.

You can use the assessment whether or not we work together.

Sources

The main legal and implementation sources for this page are: