EU Cyber Resilience Act: Status, Documentation, and Building Blocks for Your Own Compliance

The first CRA obligations will take effect from September 2026, with full compliance becoming mandatory in December 2027. Time is running out, and many manufacturers are far from ready. We provide product-related documentation, SBOMs, Threat Models, and Verified Firmware Boot as input for your conformity assessment.

The EU Cyber Resilience Act makes cybersecurity evidence mandatory for products with digital elements: initial reporting obligations will apply from September 2026, followed by comprehensive requirements from December 2027. For manufacturers of IO-Link devices, this means, in the worst case, building their own CRA documentation, Annex I mapping, SBOM process, and threat model for each product. TEConcept reduces this effort with product-related documentation, SBOMs, Threat Models, and technical building blocks as input for your own conformity assessment.

Which of our products can be CRA-relevant?

The Cyber Resilience Act applies to products with digital elements that are made available on the EU market. This can include complete hardware or software products, as well as separately provided components. For customers, it is therefore crucial to consider the role in which a TEConcept product is used: as a software component in their own end product, as a development or test tool, as a module, as a reference design, or as part of an internal development and testing strategy.

Role separation: The declaration of conformity for the finished end product lies with the respective manufacturer of the end product. TEConcept provides product-related documentation, SBOMs, Threat Models, and technical building blocks as input for the technical documentation and the customer’s own CRA conformity assessment.

CRA Relevance by Product Group

Product GroupTypical Customer UseCRA Relevance
IO-Link Stacks: Device Stack, Master Stack, Safety Device Stack, Safety Master StackSoftware component in customer-specific IO-Link Device or MasterCan be CRA-relevant if the stack becomes part of a product with digital elements made available on the EU market.
Firmware and Security Building Blocks: e.g., Verified Firmware BootTechnical security function for secure updates, integrity, and authenticity of firmwareCan be CRA-relevant if functions such as protection against manipulation, secure update mechanisms, or integrity assurance must be demonstrated in the end product.
Diagnostic and Test Systems: IO-Link Diagnosis Tool, IO-Link Spy, Device Tester, Master Tester, Physical Layer Tester, EMC Test Master / Device, Safety Master TesterTesting, diagnostic, or development tools in engineering, laboratory, service, or audit contextsCan be CRA-relevant depending on provision and use. Additionally, these tools can help to comprehensibly document development and testing processes.
Developer Tools and Modules: COD Device Emulator, 1-Port USB-C Master, 1-Port Master Module, 4-Port Master ModuleDevelopment tool, evaluation platform, module, or integration componentCan be CRA-relevant if the product is provided separately, integrated into an end product, or used as part of a product solution.
Customer-specific Integrations and ServicesProject-related adaptation, porting, security integration, documentation supportCan support the CRA conformity of the customer's product, but does not replace the final conformity assessment of the end manufacturer.

Unsure which product role applies to your case?

What we provide and what remains with the end manufacturer

TEConcept provides structured CRA documents for its own products and components as input for your technical documentation. Depending on the product, this includes SBOMs, mappings, threat models, and technical descriptions of security-relevant functions. The final risk assessment, system integration, technical documentation, and EU declaration of conformity for the end product remain with the manufacturer of the end product.

Which CRA Building Blocks TEConcept Provides

For CRA-relevant TEConcept products and components, we provide product-related documents and technical building blocks that can be incorporated into your own technical documentation and conformity assessment. The final assessment and declaration of conformity for the end product remain with the respective end manufacturer.

CRA Documentation Package for Your Conformity Assessment

Product-related supplier documentation with structured classification of CRA-relevant requirements, including functional alignment with Annex I. The package serves as input for your technical documentation, not as a substitute for your end product’s declaration of conformity.

Software Bill of Materials (SBOM)

SBOMs in CycloneDX format for TEConcept products and software components. They support transparency regarding software components and can be integrated into your own product documentation, supply chain, and vulnerability management processes.

Threat Model for IO-Link Components

STRIDE-based threat model for CRA-relevant TEConcept components, aligned with the IO-Link Security Design and Development Guideline. It supports the traceable assessment of typical threats, protective measures, and residual risks in the context of your product integration.

CRA Readiness Consulting

Project-related support for classifying and implementing technical security measures: Secure Boot, firmware signature verification, debug interface hardening, SBOM integration, documentation structure, and preparation for audit or customer requirements.

Request an example: Request a sample SBOM or a template for the CRA documentation package.

Verified Firmware Boot: Integrity Protection for IO-Link Firmware

The CRA functionally formulates technical requirements: products with digital elements must, among other things, be protected against unauthorized modification, support secure update mechanisms, and maintain the integrity of security-relevant functions. Verified Firmware Boot addresses this area as a technical building block for IO-Link Devices: the component checks whether firmware is authentic and has not been altered after signing.

New in our portfolio: Verified Firmware Boot, an add-on to our IO-Link Device Bootloader. The component cryptographically verifies the authenticity and integrity of the device firmware at each boot and each firmware update. TEConcept’s implementation uses ECDSA over the NIST-P-256 curve for this. Only firmware signed with the legitimate manufacturer’s private key can be flashed and executed on the IO-Link device. A Python script for automated generation of signed IOLFW files is included. The Python script can also be purchased separately.

Optional services on request: porting to your target hardware and alternative MCU families, integration with your PKI or HSM, and workflow training.

Verified Firmware Boot in detail: Request a datasheet or clarify in 30 minutes whether the component fits your firmware update strategy.

The IO-Link Community Security Guidelines

Our approach is based on the two security documents published by the IO-Link Community: the IO-Link Secure Deployment Guideline (V1.0.0, June 2025) and the IO-Link Security Design and Development Guideline (D1.0.0-01, October 2025). Both documents are available at www.io-link.com. They define the security architecture for IO-Link devices within the framework of IEC 62443 and set Security Level SL-C 1 as an appropriate target for embedded IO-Link field devices.

Timeline and Next Steps

SBOMs are available immediately, and Verified Firmware Boot will be part of the portfolio soon. We are rolling out the CRA documentation package and threat model product by product. If you have ongoing audits or specific time pressure, please contact us directly.

The first CRA reporting obligations for actively exploited vulnerabilities and severe security incidents apply from September 2026. The comprehensive requirements for products with digital elements apply from December 2027. Manufacturers should therefore prepare technical documentation, SBOM processes, vulnerability management, and security evidence early.

IO-Link products can be CRA-relevant if they are made available as a product with digital elements on the EU market or if they are incorporated as a software or hardware component into such a product. The product role, provision, integration, and use in the end product are decisive.

An SBOM, Software Bill of Materials, is a structured list of the software components of a product or component. It supports transparency in the supply chain and helps manufacturers identify and assess known vulnerabilities in used software components.

Verified Firmware Boot supports CRA conformity by cryptographically checking the authenticity and integrity of IO-Link device firmware. This demonstrates that only firmware signed by the legitimate manufacturer and not subsequently altered is flashed and executed.

The CRA declaration of conformity for the finished end product lies with the manufacturer of that end product. TEConcept provides product-related documentation, SBOMs, Threat Models, and technical building blocks that serve as input for the customer’s technical documentation and conformity assessment.

The CRA functionally prescribes technical requirements and does not necessarily specify a particular implementation such as ECDSA, NIST P-256, or a specific Secure Boot procedure. Manufacturers must choose appropriate measures to adequately implement and document requirements such as protection against manipulation, secure updates, and integrity assurance.

TEConcept reduces the effort by providing product-related documents such as SBOMs, mappings, threat models, and technical descriptions of security-relevant functions. Customers do not have to develop this information entirely themselves but can integrate it into their own technical documentation and assessment.

Questions or specific consulting needs?

Contact us directly. In 30 minutes, we will clarify which TEConcept components may be CRA-relevant in your case and which building blocks can save you effort.

Please note our privacy policy.