Overview
The European Union Cyber Resilience Act (CRA) introduces new cybersecurity and vulnerability management obligations for software products sold in the European Union. One of the earliest and most significant deadlines arrives in September 2026, when organizations must report actively exploited vulnerabilities to EU authorities within 24 hours.
For engineering organizations building test systems, automated measurement platforms, or LabVIEW-based solutions, this requirement introduces new operational challenges. Test teams must now track software dependencies, monitor vulnerabilities, and establish coordinated response processes across their software supply chain.
The good news is that preparing for this milestone does not require reinventing engineering workflows. Instead, organizations can focus on four practical steps that establish the infrastructure needed to manage software supply chain security.
This white paper outlines those four actions and explains why they are becoming essential capabilities for modern test engineering organizations.
Four Actions Test Teams Should Take Now
Organizations that begin preparing now will find the 2026 deadline significantly easier to manage. The following four actions provide a practical starting point for engineering teams.
1. Generate and Maintain a Software Bill of Materials
A Software Bill of Materials, commonly referred to as an SBOM, is a structured inventory of all software components and dependencies included in a system.
For test systems, this may include LabVIEW packages and toolkits, instrument drivers, external libraries, operating system components, and third party software modules.
Maintaining an SBOM allows teams to quickly determine whether a vulnerability affects their software. Without an SBOM, organizations must manually investigate dependencies when vulnerabilities are disclosed. This process is slow, difficult, and prone to errors.
An SBOM provides the foundational visibility required to manage software supply chain risk and is a key building block for CRA compliance.
2. Monitor Vulnerability Databases
Once dependencies are documented, organizations must monitor vulnerability databases to determine whether any of those components contain known security issues. The most widely used vulnerability catalog is the Common Vulnerabilities and Exposures (CVE) database hosted by Mitre. The National Vulnerability Database (NVD) hosted by NIST builds on CVE data and adds severity scoring, metadata, and search tools.
For engineering teams, this monitoring process typically begins with a SBOM. An SBOM provides the structured list of software components that make up an application or system. Security tools can then compare the components listed in the SBOM against vulnerability databases to determine whether any known issues exist in those dependencies.
Once an SBOM is generated, organizations can use vulnerability scanning tools to automatically check the listed components against CVE and NVD databases. Several open source tools support this workflow. For example, tools such as OWASP Dependency-Track and Grype can ingest SBOM files and continuously scan them against known vulnerability databases. These tools alert teams when new vulnerabilities are discovered in components used within their software.
This approach allows teams to automate much of the vulnerability monitoring process rather than manually searching vulnerability databases whenever a new issue is reported.
For long lived test systems, continuous vulnerability monitoring becomes particularly important. Many test platforms remain deployed for years or even decades, and vulnerabilities may be discovered long after the original software was released. Maintaining an SBOM and periodically scanning it for vulnerabilities allows organizations to quickly determine whether their systems are affected and respond appropriately.
3. Establish a Vulnerability Reporting Process
The CRA requires organizations to provide a way for others to report vulnerabilities in their software. These reports may come from customers, security researchers, supply chain partners, or upstream component providers.
For many test and measurement organizations, the situation looks somewhat different. Test systems are often developed for internal use and may not have traditional external customers. In these cases, the vulnerability reporting process typically occurs within the organization rather than through a public disclosure channel.
Test teams should establish a documented process for working with their IT and cybersecurity teams to review and address vulnerabilities discovered in test system software. This process may include identifying a security contact within the organization, defining how vulnerability reports are submitted internally, and ensuring that issues discovered through vulnerability scanning or dependency monitoring are tracked and resolved.
Organizations that also distribute software externally, such as instrument drivers, LabVIEW packages, or reusable test frameworks, should still consider providing a public vulnerability reporting channel such as a security email address or reporting portal. Establishing a clear intake process ensures that potential vulnerabilities are received, tracked, and addressed efficiently.
4. Build a Coordinated Response Workflow
Organizations must also define internal processes for responding to vulnerabilities when they are discovered. These processes typically include evaluating vulnerability impact, determining remediation actions, notifying affected users, and reporting actively exploited vulnerabilities to authorities when required.
For test and measurement teams, the response process must also consider the operational impact of updates to production and validation systems. Test systems are often tightly integrated into manufacturing environments, and software changes may require coordination with production schedules.
As a result, organizations should establish a process for reviewing vulnerabilities and determining appropriate remediation timelines. Some vulnerabilities may be severe enough to require immediate updates and potentially an unplanned system shutdown to mitigate risk. Others may present lower risk and can be addressed during scheduled maintenance windows or planned production downtime.
These workflows require coordination across engineering, security, IT, and manufacturing teams and should be documented and tested well before the CRA deadlines arrive. Organizations that already have response procedures in place will be far better positioned to meet the 24 hour reporting requirement established by the CRA while minimizing disruption to their production environments.
Why These Capabilities Are Becoming Essential
Software security regulations are evolving rapidly across industries as governments respond to increasing cyber threats and supply chain vulnerabilities. The European Union Cyber Resilience Act represents one of the most comprehensive regulatory frameworks introduced to date, establishing cybersecurity requirements for software sold in the European Union.
The CRA applies broadly to software products and hardware systems that contain software. For organizations developing automated test systems, measurement platforms, and embedded engineering tools, this includes both internally developed software and third party dependencies used within those systems.
The first major milestone for the CRA occurs on September 11, 2026, when organizations must report vulnerabilities in their software within 24 hours if those vulnerabilities are being actively exploited.
This requirement fundamentally changes how engineering teams manage software security. Instead of reacting to security issues as they arise, organizations must maintain continuous awareness of vulnerabilities within their software supply chain.
Test systems are particularly affected because they are often long lived assets that combine multiple layers of software including test automation frameworks, measurement drivers, instrument control libraries, third party packages, and operating system components.
Many of these systems evolve over years or even decades as products are validated, manufactured, and maintained. As a result, the ability to understand software dependencies, monitor vulnerabilities, and respond quickly to security issues is becoming an essential capability for test engineering organizations.
Supporting Secure Development in the LabVIEW Ecosystem
Engineering organizations working within the LabVIEW ecosystem face unique challenges when implementing modern software supply chain security workflows. Many test systems incorporate packages and dependencies from multiple sources, including internal development teams, third party vendors, open source libraries, instrument drivers, and operating system components. These systems are often assembled over many years and may evolve through multiple generations of hardware and software platforms.
While the September 11, 2026 CRA deadline focuses specifically on vulnerability reporting obligations, the broader Cyber Resilience Act introduces additional requirements around secure software development practices and lifecycle management. These expectations align closely with established security frameworks such as NIST 800-171 and NIST 800-53, which define controls for protecting controlled information and securing software systems used in government and regulated environments.
Across these standards, a common theme emerges: organizations must implement a secure development lifecycle that incorporates security considerations throughout the software development process. This includes practices such as dependency visibility, static code analysis, vulnerability monitoring, secure package management, configuration control, and coordinated vulnerability disclosure processes. The goal is not only to respond to security issues after software is deployed, but to proactively identify and reduce risk during development.
To help address these challenges, JKI has been developing the JKI Security Suite for LabVIEW, a platform designed to help engineering organizations implement the infrastructure required for modern software supply chain security. The suite provides capabilities for generating Software Bills of Materials (SBOMs) for LabVIEW applications, analyzing dependencies across LabVIEW packages and components, monitoring for known vulnerabilities, and supporting coordinated vulnerability management workflows.
JKI is also working closely with Emerson, the steward of the LabVIEW platform, to help ensure that LabVIEW development teams will have the tools and workflows necessary to meet the evolving security expectations defined by the CRA and related security frameworks. Together, these efforts aim to support the long term security and sustainability of the LabVIEW ecosystem while helping engineering teams adapt to emerging regulatory requirements.
While organizations do not need to fully implement secure development lifecycle practices before the September 2026 CRA reporting deadline, these capabilities will become increasingly important as security regulations continue to evolve. Establishing the right tooling and processes now will help engineering teams reduce long term compliance risk while improving the resilience of the systems they build.
For more information about secure development practices for LabVIEW systems, organizations can review the Security Summit presentation delivered on March 11, 2026, or join the JKI team at NI Connect in Fort Worth, Texas, where these topics will be discussed in greater detail.
Conclusion
The EU Cyber Resilience Act represents a major shift in how organizations must manage the security of software products and digital systems. For test and measurement teams, the September 2026 vulnerability reporting requirement introduces new responsibilities that extend beyond traditional engineering workflows.
Preparing for this change requires organizations to establish visibility into their software supply chains, monitor vulnerabilities continuously, and implement coordinated response processes.
By focusing on four practical actions generating SBOMs, monitoring vulnerability databases, establishing reporting channels, and defining response workflows engineering teams can position themselves to meet CRA requirements while improving the long term security of their test systems.
Organizations that begin preparing today will reduce compliance risk and strengthen the resilience of the systems they build.
To learn more about improving security for LabVIEW based software systems or developing an actionable plan for CRA readiness, organizations are encouraged to connect with JKI, security@jki.net, for additional resources and guidance.
Enjoyed the article? Leave us a comment