Details
Why the CRA’s September 2026 reporting requirements make software visibility, vulnerability management, and compliance preparation an immediate priority.
The EU Cyber Resilience Act affects companies based on where their products are sold, not where those companies are headquartered. US organizations that place connected products on the EU market may therefore need to comply with its vulnerability-reporting, security-by-design, documentation, support, and CE-marking requirements.
In this session, Qt Group’s Corey Pendleton and Kyle Edens explain the difference between the September 11, 2026 reporting obligations and the broader December 2027 compliance deadline. They outline four readiness priorities: a five-year security patch commitment, machine-readable SBOMs, the ability to investigate and report actively exploited vulnerabilities within 24 hours, and audit-ready evidence of systematic security testing.
The September 11, 2026 milestone introduces vulnerability and incident reporting requirements, including an early-warning obligation for actively exploited vulnerabilities and severe security incidents.
The December 2027 milestone covers the CRA’s broader product requirements, conformity assessments, and CE marking. Teams that plan only around the 2027 deadline may overlook reporting capabilities they need much sooner.
The CRA applies according to where a product is made available, not simply where its manufacturer is headquartered.
A US company selling connected products in the EU may be subject to the regulation. The session emphasizes evaluating individual product categories rather than assuming that a company’s location or industry automatically places it outside the CRA.
The September 2026 reporting requirements are not limited to newly launched products. Products already available in the EU market may also be covered when an actively exploited vulnerability or severe security incident is identified.
Organizations therefore need visibility into the software components and vulnerabilities within their current product portfolio, not just products under development.
The CRA moves security from a post-development activity to a product requirement that begins at inception.
Teams need to address risk management, secure default configurations, access controls, data protection, vulnerability handling, testing, and documentation throughout the software development lifecycle. Compliance cannot be achieved by adding a security review immediately before release.
Manufacturers are responsible for more than their own source code. They must also understand the third-party libraries, open-source components, frameworks, and other dependencies included in their products.
A machine-readable software bill of materials provides the inventory needed to determine whether a newly disclosed vulnerability affects a product. Generating the SBOM during the build improves accuracy because it reflects the components actually shipped.
The session identifies a five-year security update commitment as one of the central readiness questions for software manufacturers.
Teams need to align product launches, framework versions, long-term support windows, and expected field lifetimes. A dependency that reaches end of support before the product does can create both security and compliance risks.
A 24-hour reporting deadline cannot be met through policy documents alone. Organizations must be able to identify an affected component, connect it to deployed products, assess the incident, gather supporting evidence, and begin the required reporting process quickly.
That capability depends on accurate inventories, vulnerability-notification channels, clear ownership, documented escalation procedures, and continuously maintained product data.
The CRA requires organizations to demonstrate systematic security testing and security-by-design practices.
Automated functional testing, code-coverage measurement, architecture analysis, and risk-assessment documentation can help establish that the software was tested as designed. These capabilities are also important when applying urgent security patches, since remediation must not introduce regressions or break critical product functionality.
Compliance preparation should focus on the earlier deadline
Practical implication: Separate the September 2026 reporting workstream from the December 2027 conformity and CE-marking program.
Product location determines scope
Practical implication: Inventory every connected product sold in the EU and assess each product category with qualified legal counsel.
Dependency visibility is foundational
Practical implication: Generate a machine-readable SBOM during every build and maintain it as the product and its dependencies change.
Support lifecycles affect regulatory exposure
Practical implication: Compare each product’s expected market lifetime with the support windows of its frameworks, libraries, and other critical dependencies.
Vulnerability reporting requires rehearsed processes
Practical implication: Define ownership, escalation paths, evidence requirements, and reporting workflows before an actively exploited vulnerability is discovered.
Security fixes need regression protection
Practical implication: Maintain automated tests and code-coverage evidence so urgent patches can be released quickly without sacrificing product reliability.
Architecture is part of security governance
Practical implication: Track APIs, dependencies, and communication paths so unplanned interfaces or architectural changes do not introduce unnoticed exposure.
Q: What is the EU Cyber Resilience Act?
A: The Cyber Resilience Act is an EU regulation establishing cybersecurity requirements for products with digital elements. It covers areas such as security by design, vulnerability handling, software-component visibility, security updates, technical documentation, reporting, and conformity assessment.
Q: Does the CRA apply to US companies?
A: It can. The session explains that the CRA applies according to where a product is sold or made available. A US company placing connected products on the EU market may therefore be within its scope.
Q: What happens on September 11, 2026?
A: The CRA’s vulnerability and incident reporting obligations begin to apply. Organizations need the operational capability to provide an early warning concerning actively exploited vulnerabilities and severe security incidents within the required timeframe.
Q: What happens in December 2027?
A: The CRA becomes fully applicable, including its broader product-security, conformity-assessment, and CE-marking requirements.
Q: Does the reporting requirement apply to products already on the market?
A: Yes. According to the session, the September 2026 reporting requirements apply to existing products as well as new products available on the EU market.
Q: What is an SBOM, and why is it important?
A: A software bill of materials is an inventory of the components contained in a software product. A machine-readable SBOM helps teams identify affected products when vulnerabilities are discovered in frameworks, libraries, or other dependencies.
Q: Why should an SBOM be generated during the build?
A: Build-time generation reflects the components actually included in the shipped product. Attempting to infer dependencies from compiled binaries may miss transitive or source-level components and produce less reliable compliance documentation.
Q: What four questions should teams use to assess readiness?
A: The session recommends asking whether the organization has:
A five-year security patch commitment.
A machine-readable SBOM covering third-party and open-source components.
The ability to investigate and report an actively exploited vulnerability within 24 hours.
Audit-ready evidence of systematic security testing.
Q: Why does test automation matter for CRA preparation?
A: Automated testing and code-coverage evidence help demonstrate that teams systematically tested what they built. They also reduce the risk that an urgent security patch will break existing functionality.
Q: What should organizations using an older Qt version do?
A: The speakers recommend evaluating the product’s support requirements and planning a migration path to a supported Qt 6 release. Extended security maintenance may provide a temporary bridge for certain commercial customers, but it is not presented as a substitute for a long-term migration plan.
Dominique Roller: Hello, everyone, and welcome to today’s DZone webinar, “The Cyber Resilience Act: What Waiting Is Costing US Software Teams.” I’m Dominique Roller, and I will be your host for today’s session.
The EU Cyber Resilience Act is quickly becoming a practical concern for software teams well beyond Europe. Starting September 11, 2026, companies face new requirements to report actively exploited vulnerabilities and severe security incidents within 24 hours.
Because the CRA applies based on where a product is sold, US companies that sell connected products in the EU could be directly affected.
There is a lot to unpack, but we’ll get started shortly. Before we get into everything, let’s review our housekeeping notes.
Today’s session is being recorded, and we’ll share the on-demand recording with registrants after the event. If you have any questions during the presentation, please submit them using the Q&A tab. We’ll address as many as we can during the Q&A portion at the end.
With those details covered, let’s shift our focus to the impact of the CRA.
For engineering and product teams, preparing for the CRA goes beyond understanding a new regulation. Meeting a 24-hour reporting window depends on having the visibility and processes to quickly understand what is in your software, where vulnerabilities exist, and how serious an incident really is.
In today’s session, you’ll gain practical insights into the difference between the CRA’s September 2026 reporting requirements and the broader December 2027 compliance and CE-marking deadline.
You’ll also learn why US software companies can fall within the CRA’s scope when their products are sold in the EU, and how capabilities such as software-dependency visibility, SBOMs, test coverage, and security-by-design practices can help teams prepare for the reporting and compliance demands ahead.
To help us break all of this down, I’m pleased to introduce our speakers from Qt Group.
Corey Pendleton is Senior Director of Customer Engineering, and Kyle Edens is Vice President of Sales for the Americas.
Corey and Kyle, thank you both for joining us today. I’ll hand it over to you.
Kyle Edens: Thank you for the introduction, Dominique.
Before we get started, a quick note about what is shown on the screen. This presentation is for informational purposes only and reflects Qt’s current understanding of the CRA. It is not intended as legal advice. For requirements specific to your products or jurisdiction, please work with your legal counsel.
From a high-level agenda standpoint, I’ll walk the team through what the CRA is and why it is more impactful than many people realize.
Corey will then take us through the technical components, focusing on long-term supported releases and lifecycles, quality-assurance tools, and the specific requirements Qt is addressing to support CRA compliance.
Before we get started, we want to hear from you. Think of this as the first step in your CRA readiness checklist.
I see some answers coming into the poll. That’s great. Please note that there is no right or wrong answer. It simply helps us make the session more relevant to the needs of this group. Thank you, everyone, for participating.
What is the EU Cyber Resilience Act?
Before we dive into the details, it’s important to note that the CRA is a regulation, not a directive. That distinction matters. It is directly binding across EU member states without needing to be transposed into national law.
Some of you may be familiar with the NIS2 Directive, which focuses on organizational cybersecurity and risk-management measures. The CRA targets the products themselves.
If your product has a chip, firmware, embedded software, or a connected component, it may be within scope.
The shift demanded by the CRA is moving security from something addressed after production to something that is architected from day one.
Another important point is that you are responsible not only for your own code but also for every third-party library, open-source component, and cloud API included in your product. That has real implications for how you manage your software supply chain.
We also receive many questions from customers in regulated industries such as medical devices, automotive, and aviation. They ask whether the CRA applies to them.
The answer depends on the specific product. Certain EU regulations, such as the Medical Device Regulation or aviation-specific rules, may overlap with or satisfy some CRA requirements. However, the CRA does not simply exempt entire industries.
For example, a medical-device company that also makes hospital-administration software, connected monitoring portals, or a general-purpose embedded control system may have products that fall under the CRA rather than solely under the Medical Device Regulation.
The safest approach is to check each product category with your legal team. Do not assume that your industry label resolves the question.
Let’s discuss the key deadlines and why the clock is running.
The first and most pressing deadline is in September. What many people miss is that the September 2026 deadline is not limited to new products. It applies to products already on the market as well.
If you identify an actively exploited vulnerability, you may be legally required to provide an early warning to ENISA within 24 hours.
If your team is building products for 2026 or 2027, you are already developing within the CRA window. The question is not whether this will affect you. It is whether you will be ready when it does.
From a compliance-exposure standpoint, there are three levels of penalties.
The first and most serious tier can reach €15 million or 2.5% of total worldwide annual turnover, whichever is higher. This applies to failures involving essential cybersecurity requirements in Annex I, such as known exploitable vulnerabilities, secure default configurations, and appropriate access controls.
The second tier can reach €10 million or 2% of total worldwide annual turnover, whichever is higher. This covers violations of other CRA obligations, including Article 14 reporting obligations and conformity-assessment failures.
The third tier can reach €5 million or 1% of total worldwide annual turnover. This applies to supplying incorrect, incomplete, or misleading information to notified bodies or market-surveillance authorities.
This tiered structure is important because the middle and lower tiers can include administrative failures, not just technical security failures.
A product that is genuinely secure but has a poorly maintained SBOM or misses a reporting deadline can still create significant compliance exposure.
The question is not simply whether your product is secure. It is whether you can prove that it is secure and report the required information correctly and on time.
Before Corey takes you through the specifics, here is where we stand at Qt.
Qt has built its CRA response into the product roadmap. These are not simply positioning claims. They are specific capabilities associated with particular CRA requirements.
Corey will show you how each one maps. Corey, over to you.
Corey Pendleton: Thanks, Kyle.
The CRA requires manufacturers to demonstrate several capabilities across the software development lifecycle. This affects the processes used to develop software as well as the software that is ultimately released.
One of the first considerations is security by design. That applies from the beginning of the development lifecycle, starting at inception, rather than only at deployment.
Secure by design means that a product is built securely rather than made secure later. It is critical that you can show your work and demonstrate how you created a secure product from its inception.
Risk management then applies throughout the lifecycle, with every engineer carrying responsibility for understanding the threat vectors affecting their code.
Products must also be secure by default. Settings related to access management, default root passwords, and data protection at rest and in transit must be considered and incorporated into the product’s default deployment configuration.
Next, you need a process for managing vulnerabilities. Vulnerabilities are not a matter of if; they are a question of when.
In a world of AI-powered penetration testing and open-source dependencies, discovering vulnerabilities is only a matter of time.
Those of us who have worked in technology long enough remember what happened in 2021 when the Log4j vulnerability was announced. The entire web industry scrambled to patch the vulnerability and avoid widespread compromises of global web infrastructure.
That is exactly the type of situation the CRA is designed to address. Log4j was a dependency on open-source software that did not necessarily follow a support and maintenance cadence aligned with every product that used it. Manufacturers need to take responsibility for those dependencies.
Finally, documentation is the proof of what you have done. It shows your work.
The CRA requires product features designed with security in mind, but it also requires internal processes, assessments, and documentation that demonstrate that your organization is taking the appropriate steps.
Selecting a product or platform that supports these requirements can be critical to controlling costs and making the development process faster and easier.
Qt Group can make it significantly easier to provide documentation for the parts of a platform built using our framework. You remain responsible for the rest, but there is a great deal to consider, with implications for many teams involved in product development.
We’ve tried to simplify this into four key questions that can help determine your readiness. See whether you can answer yes to all four.
We’ve tracked the CRA since it was announced in 2022, so we have been able to map our products to these kinds of requirements.
The first question is: Do you have a five-year patch commitment?
CRA Article 13 requires manufacturers to provide security updates for a minimum support period that is generally expected to be at least five years, subject to the product’s expected use.
Do you have a patch plan to support your products if security vulnerabilities are discovered during that period?
The second question concerns the software bill of materials.
CRA Annex I, Part II requires manufacturers to identify and document product components, including through a machine-readable SBOM covering at least the product’s top-level dependencies.
Do you have a machine-readable SBOM covering the relevant third-party and open-source components in your product?
This is not limited to your own code. It is critical because it establishes a baseline for understanding your obligations.
It also supports automated identification of new and changing dependencies. Products are not static. They evolve, and customers expect changes.
As a product evolves during maintenance, are new dependencies added? Are older dependencies removed?
Automatically generating an SBOM gives you that information and can help limit the cost of compliance.
The third question concerns Article 14 and its reporting obligations.
Could your team detect, investigate, and begin reporting an actively exploited vulnerability affecting a software dependency anywhere in your system within 24 hours?
That is the point. Starting with the reporting provisions, organizations marketing covered products in the EU must be prepared to meet those obligations.
Finally, conformity assessment requires documented evidence of systematic security testing.
If you’re an engineer attending this webinar, you recognize the importance of security testing. However, it often gets postponed until later in the process. That can no longer be the standard approach.
Teams need to follow best practices for security testing and architecture management to ensure that vulnerabilities are not being introduced. Compliance requires more than passing a build.
We’ll talk about some of the products Qt Group provides that can help demonstrate how a product performs against those standards and supply supporting documentation.
Perhaps most importantly, as you make changes to address discovered vulnerabilities, you must ensure that your product remains functional and that those fixes do not inadvertently break functionality for end users.
Some of these products are part of our quality-assurance portfolio.
Squish supports automated testing. Coco measures code coverage and helps teams determine whether the software they have written has been exercised by their tests.
These products are commonly used in regulated markets and can be incorporated into development workflows to support compliance evidence.
Let’s consider five years of support using the Qt framework roadmap as an example.
Once we understood the requirements in Article 13, we adjusted our roadmap and plans to support longer security-maintenance periods.
Qt 6.8 has been available since October 2024. It was our first release with five years of standard support, including security maintenance.
Qt 6.12, scheduled for release in September 2026, is our first release developed using a process designed to support CRA requirements.
Remember that products need to be developed with security in mind from inception rather than made secure later. The Qt framework has adopted that approach, beginning with Qt 6.12.
It is important to choose platforms that provide this type of documentation and support because doing so reduces the work manufacturers must perform for the portions of their products built on those platforms.
With supported Qt products moving forward, customers receive documentation addressing relevant CRA Annex I requirements, automated SBOM generation in machine-readable formats, risk assessments, and supporting evidence.
For products preparing to ship on Qt 6.12, the standard long-term support window aligns with the anticipated CRA support obligation.
If you release a product now or shortly after the release, you can plan to update your Qt version approximately every four years. That allows you to maintain supported framework versions on an ongoing basis and gives you a clearer understanding of the maintenance costs required.
For products that outlive an LTS window, or when upgrading becomes too costly, we also offer extended security maintenance. That service can continue supplying focused patches that resolve vulnerabilities while minimizing functional changes to the framework.
This limits the scope of changes and can help control maintenance costs. It is available through applicable commercial agreements with Qt Group.
Open-source community editions do not carry the same contractual support commitment. There is no guaranteed schedule for support, minor patches, or vulnerability remediation. This consideration applies to any framework you select.
The practical advice is to align product launches with LTS windows whenever possible. You should also understand the expected field lifetime of each product so you can manage maintenance costs and keep the product supported throughout its useful life.
Let’s discuss SBOM generation.
Beginning with Qt 6.8, we support SBOM generation using the SPDX 2.3 format, which is widely used across the industry.
The SBOM covers the Qt framework as well as our third-party dependencies and open-source libraries.
These are components that conventional third-party binary scanners may miss because they do not have access to the source and may not identify every underlying dependency.
Because we generate the SBOM at build time rather than attempting to infer it from binaries, it reflects what is actually shipped.
That matters for the accuracy of your Annex I deliverables and the credibility of your conformity documentation.
Qt 6.12 adds support for the CycloneDX 1.5 standard, which is widely used within DevSecOps. That provides additional automation for DevSecOps teams and supports their efforts to secure products and development environments.
Qt became an authorized CVE Numbering Authority in April 2025. That means we now manage the assignment and disclosure process for Qt vulnerabilities from end to end.
For commercial customers, this provides access to an early-warning list with pre-disclosure notifications before CVEs become public.
For any team with a 24-hour ENISA reporting obligation, that advance notice can make the deadline much more achievable.
Customers can receive early notice, particularly when a vulnerability is actively being exploited, allowing them to address their reporting obligations with less delay.
Qt sees approximately 10 CVEs per year across the framework, and that number is trending upward. AI-assisted penetration testing is revealing vulnerabilities that were previously undetected.
Without a centralized notification channel, tracking vulnerabilities across public databases becomes a manual process that team members must manage.
Every tool and open-source framework requires someone to monitor its vulnerabilities unless that work is consolidated and covered by a supported software platform.
Our Product Security Incident Response Team follows a response cadence designed to support customers’ reporting needs.
We target 24 hours for acknowledging an actively exploited vulnerability, giving customers the initial information needed for regulatory reporting; 72 hours for an early assessment of the required patch effort; and 14 days for a resolution path.
For vulnerabilities that are not being actively exploited, fixes may be made available before exploit information becomes public. In the best circumstances, a vulnerability is corrected and a fix is provided before it becomes publicly known or exploited.
At the end of the day, we become a point of accountability. We manage triage, scoring, and advisory publication for the Qt framework.
When software depends on Qt, customers can rely on the framework’s supporting coverage and documentation for those components.
Finally, let’s return to security by design.
This includes threat analysis, risk-assessment documentation, ISO-certified processes, and additional CRA-focused security analysis and guidance for building secure software with the Qt framework.
These resources are available with applicable Qt commercial licenses.
Coco is our code-coverage tool. It helps determine whether tests cover relevant branches and conditions and whether teams are examining potential paths for security vulnerabilities. Its capabilities include branch and condition coverage and modified condition/decision coverage, or MC/DC. This can provide supporting audit evidence.
Squish provides test automation. It removes some repetitive manual work from quality-assurance teams and helps ensure that regressions do not occur.
Software will need to be patched, and every patch carries cost and risk. An automation tool that verifies functionality from end to end is important for reducing that risk.
CRA Annex I, Part I requires security by design. You need documented evidence showing what you tested and that your testing addressed what you built.
Tools for automated testing and code coverage can help provide that evidence.
Security also affects how you design the software’s architecture. Unexpected APIs can easily be introduced. An unplanned REST API, for example, can expose a web service to serious vulnerabilities.
Although an API might satisfy a feature requirement, teams may not identify its security implications during development. Resolving the problem later can become expensive.
Another valuable capability is therefore architecture governance: understanding the dependencies and connections between software layers and verifying that the implementation remains aligned with the intended design.
Qt Group provides a tool called Axivion that can offer visual and class-level information about dependencies and architecture compliance. It helps teams verify that software remains consistent with the secure architecture established during design throughout the development lifecycle.
Ultimately, the CRA creates a financial incentive to invest in quality assurance. As engineers know, the best practice is to begin that work early and maintain it throughout the product development lifecycle.
Kyle, I’ll hand it back to you to wrap things up.
Kyle Edens: Thank you, Corey.
Before we take questions, let’s return to the checklist we opened with.
We began the session by highlighting two things we wanted everyone to understand: what to establish for the September 11 reporting requirements and what to begin building toward for the December 2027 deadline.
Corey walked us through four checklist questions:
Do you have a five-year patch commitment?
Do you have a machine-readable SBOM?
Can you support the 24-hour reporting requirement?
Do you have audit-ready testing evidence?
Those four questions do not change based on the technologies you use. Whether you use Qt, something else, or are still deciding, that is the fundamental checklist.
What follows is specifically what the path looks like for Qt, because that is what we can speak about directly.
If you are a commercial customer using Qt 5.15, that version will not receive CE marking from Qt under the CRA roadmap.
Any product you continue selling into the EU market needs a defensible security-maintenance path for the applicable support period, and Qt 5.15 does not provide that path by itself.
What we can offer is extended security maintenance. It is available now and can provide a transition period while you plan a migration to Qt 6.12.
If you are in this situation, I suggest speaking with your dedicated Qt contact after this session so we can help you establish a plan.
If you are using a commercial Qt 6 release, you are in a stronger position. Depending on the version and agreement, capabilities such as LTS support, SBOM generation, and early-warning access may already be available.
I would ask you to plan your path to Qt 6.12, scheduled for release at the end of September. It is the first Qt version fully developed using a process designed to support CRA requirements.
If you are not already on the early-warning list at account.qt.io, sign up. Most importantly, map your product-launch dates against the LTS calendar before your development timelines become fixed.
If you are currently a Qt open-source user, we’re available to help you understand what compliance may require for your product.
The honest reality is that the community edition does not include contractual long-term support, Qt-backed SBOM support, or access to the commercial early-warning list. As the manufacturer, you carry the responsibility for satisfying the applicable requirements.
Open-source Qt 5.15 patch releases stopped with version 5.15.2 in November 2020. For some products, managing that responsibility independently may be possible. For others, it may not be.
The only way to determine that is to evaluate your circumstances. If you would like to connect with a Qt account manager, let us know, and we can look at your specific situation more closely.
There are a few things to keep in mind before we move into the Q&A.
Remember the poll at the beginning. Whether you are just getting started or believe you are largely prepared, the four checklist questions and the paths we discussed should give you a concrete next step.
If there is one thing I want everyone to leave with, regardless of what you are building with, it is this: If you are unsure where to start, that is what the CRA workshop is designed to address.
It is a focused session, typically lasting an hour to an hour and a half, involving CRA stakeholders from your team, your dedicated Qt account manager, and our technical presales team.
The output is a clearer picture of where you stand against the CRA’s requirements and an outline of the concrete next steps needed to close the gaps. It is intended as a working session.
For those building with Qt, there are a couple of specific things worth doing this week.
Confirm whether you are using at least Qt 6.8 to access the available SBOM-generation capabilities and five-year LTS window. If you are a commercial license manager, sign up for the early-warning list through the Qt Account portal.
December 2027 may feel like a long way off, but current development cycles already fall within the broader CRA preparation window. The time to resolve these issues is now.
If you are an open-source Qt user and need contractual LTS, Qt-supported SBOM generation, or early-warning access, those are commercial-license capabilities that we can discuss.
If anyone would like a deeper session focused on a specific product and how it maps to CRA requirements, we can arrange that.
I think we’re ready to move into the Q&A.
Dominique Roller: Thank you, Corey and Kyle.
That was a helpful look at what the Cyber Resilience Act means in practice and why the September reporting requirements make preparation an immediate priority for software teams.
I’m excited to move into the Q&A portion of the session. As a reminder to our audience, you can submit questions using the Q&A tab.
Corey and Kyle, let’s address a few questions from our audience.
The first question is: “We haven’t started anything yet. Where should we actually begin?”
Kyle Edens: That question is directly on theme.
A good first step is a readiness assessment. For Qt customers, that can include our CRA workshop, which lasts approximately an hour to an hour and a half.
It brings together your organization’s CRA stakeholders, the Qt account team, and our technical team to map your current position and identify the next steps.
Dominique Roller: That workshop sounds like a useful opportunity for members of the audience.
Our second question is: “Does the September 11 reporting deadline apply to products we already have on the market or just new ones?”
Kyle Edens: It applies to products already available in the EU market as well as new products being launched.
Dominique Roller: How do we generate an SBOM, and does Qt help with that?
Corey Pendleton: Yes, we help with that.
Beginning with Qt 6.8, which has been available since 2024, we generate a machine-readable SBOM using the SPDX 2.3 format.
It includes Qt’s own software and libraries as well as our third-party and open-source dependencies.
The SBOM is generated at build time and is available to eligible commercial customers through the Qt Account portal and commercial Qt repository.
Dominique Roller: We’re running low on time, so I’ll take one more question.
“We’re still on an older Qt 5 version. What is a realistic migration path before all of this takes effect?”
Corey Pendleton: That’s a good question, and many customers are in that situation.
As Kyle mentioned, Qt 5.15 will not receive CE marking from Qt under our CRA roadmap. That cannot be the final long-term solution for a new product that must meet the full requirements after December 2027.
If your product is currently based on Qt 5, extended security maintenance may provide certain security patches for the legacy software. However, it should be viewed as a temporary measure while you plan a migration to Qt 6.
You should plan to move to a supported Qt 6 release, with Qt 6.12 being the release developed using a process designed to address CRA requirements.
If you are using a Qt 5 release earlier than 5.15, moving first to Qt 5.15 may make the transition to Qt 6 easier.
We can assist through analysis, the CRA workshop, and consulting services with experience in these migrations.
Dominique Roller: You heard it from them: This is not the time to procrastinate. It is better to begin while you still have time to prepare.
Thank you both for today’s discussion.
You made it clear that preparing for the CRA is not simply about working toward a 2027 compliance deadline.
The 24-hour reporting requirement puts much earlier pressure on teams to understand their software, identify vulnerabilities and dependencies quickly, and maintain the evidence and processes needed to respond when an incident occurs.
For US organizations selling connected products in the EU, that makes the CRA a near-term operational consideration, not simply a future European regulatory requirement.
You both gave us valuable information, and we appreciate it.
To our audience, if we weren’t able to answer your question during today’s session, Qt Group can follow up. If you would like to learn more, be sure to review the resources shared today.
Corey and Kyle, before we wrap up, I’d like to hand it back to you to explain how attendees can continue the conversation and learn more about preparing for the Cyber Resilience Act.
Kyle Edens: Thank you, Dominique, and thank you to everyone in our audience for your time today.
Our contact details are on the screen. Please don’t hesitate to contact Corey or me if you have questions or follow-up actions after the session.
Qt also has a dedicated Cyber Resilience Act page on qt.io. For early-warning access, commercial customers should visit account.qt.io and sign up through the Qt Account portal.
Thank you again. We sincerely hope this session was valuable.
Dominique Roller: Thank you, Corey and Kyle, and thank you to everyone who joined us today.
Keep an eye on your inbox for the on-demand recording. We hope to see you again at a future DZone webinar.
Presenters:
Corey Pendleton
Senior Director, Customer Engineering, Qt Group
Kyle Edens
Vice President of Sales, Americas, Qt Group
Join Now for More Content & Events
For event and sponsorship inquiries, please email: [email protected]
