Following the first part of our Ask Our Experts campaign on the Cyber Resilience Act (CRA), we are continuing with another set of practical questions submitted by software vendors and companies operating in regulated environments.
This time, our experts address topics such as SaaS platforms, offline systems, internal software tools, vulnerability disclosure processes, technical documentation, audits, enforcement, and ongoing compliance expectations.
We already work under ISO 13485 and IEC 62304. Can we use our existing quality system, or do we need to set up something separate specifically for the CRA?
The CRA does not mandate any specific cybersecurity risk assessment methodology. You do not need to start from scratch. You can absolutely map the CRA requirements into your existing QMS processes, such as those used for ISO 13485. You just need to ensure that your methodology effectively identifies, evaluates, and documents the specific cybersecurity threats and risk treatments required by the CRA, allowing market surveillance authorities to verify how you mitigate those risks.
What does “secure by default” mean in practice for software vendors? For example, are there specific expectations around disabling all non-essential ports, enforcing MFA, password policies, or hardened default configurations?
In practice, “secure by default” means that when your laboratory client boots up your software out of the box, the strictest security settings must already be automatically enabled. The exact configuration depends on your risk assessment, but yes—it typically means disabling unused network interfaces, shipping with deprecated algorithms disabled, or enforcing appropriate access management controls, such as authentication and strict password policies, by default. A user may subsequently decide to change those settings to fit their specific lab workflow, but the manufacturer is legally responsible for ensuring the baseline configuration is secure on delivery.
Our software is built on top of a lot of third-party libraries. What do we need to do to show that we’ve checked them properly?
This is a very common concern since open-source code is everywhere! You are perfectly allowed to integrate open-source components without a CE mark. The law simply requires you to exercise and document “due diligence” to ensure they do not compromise your final product.
The level of diligence depends on the component’s risk. Practically speaking, you can prove this by documenting actions such as: checking the component’s update history to see if it is actively maintained, verifying it against public vulnerability databases, reviewing its Software Bill of Materials (SBOM), or running your own security tests like fuzzing or penetration testing.
The regulation requires us to draw up an SBOM. What exact level of detail is required for our dependencies, and are we legally required to make this document publicly available to our users?
You will be happy to hear that you are not legally obliged to make your SBOM public. It is primarily an internal tool to help you track vulnerabilities and must be provided to market surveillance authorities only upon a reasoned request. As for the level of detail, the CRA requires the SBOM to be in a commonly used, machine-readable format and to cover, at a minimum, the “top-level dependencies” of your product.
Source: Pixabay
Besides an SBOM and general QMS records, what evidence are software vendors realistically expected to maintain for compliance purposes? For example, do we need to keep audit trails, vulnerability logs, or risk assessments throughout the product lifecycle?
Yes, your documentation must be continuous and dynamic. Besides the SBOM, you must systematically document and continuously update your cybersecurity risk assessment throughout the entirety of the product’s support period. You must keep reports of all the security tests you carry out, log the vulnerabilities you become aware of, and document the corrective actions and handling processes you used to mitigate them. All of this forms your “technical documentation,” which you must keep at the disposal of market surveillance authorities for at least 10 years after the product is placed on the market, or for the duration of the support period, whichever is longer.
Do we need to do things like penetration testing or fuzz testing for CRA compliance, or is that up to us to decide?
The CRA is designed to be technology-neutral, meaning it does not strictly mandate one specific type of test (like mandatory third-party penetration testing) for all products. Instead, it requires you to apply “effective and regular tests and reviews” of your product’s security. The specific types of tests you choose (whether that is fuzz testing, penetration testing, or software composition analysis) and how frequently you do them must be proportionate to the cybersecurity risks you identified during your risk assessment. You must document the methodology you choose so that market surveillance authorities can verify how you evaluated and mitigated those risks.
A question regarding public vulnerability disclosure policy: how formal does this process actually need to be? Is providing a simple contact email enough, or are regulators expecting a fully documented, coordinated vulnerability disclosure program?
While providing a contact email is a baseline requirement, regulators expect a formal, structured process. The CRA explicitly mandates that manufacturers “put in place and enforce a policy on coordinated vulnerability disclosure”. In practice, this means you need a documented, structured process that enables individuals (such as ethical hackers or users) to report vulnerabilities to you so that your team can diagnose and remedy the flaws before detailed information is disclosed to the public or third parties. Providing a simple contact address is just one piece of this broader, structured policy.
Download the Cyber Resilience Act (CRA) Readiness Checklist to turn requirements into actionable steps.
Get a practical overview of what CRA compliance means for your product, including:
✔ Key cybersecurity requirements across the product lifecycle
✔ “Secure by design” and “secure by default” principles
✔ Documentation, conformity, and CE marking essentials
✔ Post-market obligations, including monitoring and incident reporting
If we find a vulnerability that’s actively being exploited, how quickly do we need to report it to ENISA and the CSIRT? What happens if we don’t have a patch ready within 24 hours?
Don’t panic—you are not expected to have a patch ready in 24 hours! The timeline works like this: you must submit an “early warning” notification within 24 hours of becoming aware of the actively exploited vulnerability. You then have up to 72 hours to submit a more detailed vulnerability notification, which can include initial mitigating measures or workarounds that users can take. Your final report is not due until 14 days after you have actually made a corrective or mitigating measure available.
Is it true that security updates must be provided separately from functionality updates? What if a security fix fundamentally alters how our lab instrument processes data?
You only have to separate them “where technically feasible”. The CRA understands that sometimes a functionality update is absolutely necessary to deliver a security fix. For instance, if patching a vulnerability means replacing a data parser that results in a slightly different functional behavior for your lab instrument, you are allowed to bundle them. The regulation simply wants to prevent vendors from forcing users to install unrelated feature updates purely to get the latest security patches.
Once a product has been CE marked and released, what is the process for demonstrating continued compliance? Can authorities request source code or on-site audits?
Once released, you must continuously monitor your product to ensure it remains compliant. If a national Market Surveillance Authority suspects a risk, they can issue a reasoned request for access to the data required to assess your design, development, production, and vulnerability handling, including internal documentation. While the CRA emphasizes the protection of intellectual property and trade secrets (explicitly mentioning source code), authorities have broad powers to access the data they need to verify compliance.
Regarding on-site audits: if you use a Notified Body to assess your software (for example, under Module H for full quality assurance), that Notified Body will conduct periodic audits, including assessment visits to your manufacturing and development premises, to ensure your quality system remains effective. Market Surveillance Authorities can also conduct coordinated control actions (known as “sweeps”) to inspect products across the market.
What are the fines for non-compliance with CRA, and which authorities would be responsible for investigating and enforcing them?
The financial penalties for non-compliance are severe. If you fail to meet the essential cybersecurity requirements or the mandatory vulnerability reporting obligations, fines can reach up to €15,000,000 or 2.5% of your total worldwide annual turnover for the preceding financial year, whichever is higher. Other administrative failures (such as incorrect technical documentation or missing CE marking) can result in fines of up to €10,000,000 or 2%. These rules will be enforced and investigated by the designated national Market Surveillance Authorities in each EU Member State.
Our engineering team is based outside the EU, but we sell software directly to EU-based customers. Who carries the CRA obligations in this scenario?
If you are a manufacturer based outside the EU, you cannot sell products directly to EU customers without an economic operator established within the Union taking on specific responsibilities. You will need to appoint an EU-based “importer,” an “authorised representative,” or rely on a “fulfilment service provider” located in the EU. This EU-based entity will be legally responsible for ensuring your software has the correct EU declaration of conformity, maintaining the technical documentation, and cooperating with market surveillance authorities on your behalf.
The questions submitted during this campaign clearly show that many software vendors are still navigating how CRA requirements apply in practice – especially in complex and regulated environments.
Preparing for the CRA is not only about meeting future compliance obligations, but also about building more secure, maintainable, and transparent software products over the long term.
