On 27 July 2026, the European Commission published practical guidance on the application of the Cyber Resilience Act (CRA). The guidance is non-binding, but it is the clearest indication yet of how the Commission expects manufacturers, developers and market-surveillance authorities to interpret the Regulation.
For the physical access sector, this matters. Electronic keys, access-control readers, management software, IGA products and the connectors between them increasingly form one digital ecosystem. The CRA makes cybersecurity a product-lifecycle obligation across that ecosystem - from secure design and conformity assessment to vulnerability handling, security updates and incident reporting.
The first CRA reporting obligations apply from 11 September 2026. The main product requirements apply from 11 December 2027. Waiting until 2027 is therefore not a realistic compliance strategy.
What the new guidance clarifies
The CRA applies to software and hardware products with digital elements that are made available on the EU market in the course of a commercial activity and have a direct or indirect logical or physical data connection to a device or network. The Commission's guidance adds practical detail in five areas that are especially relevant to access technology:
1. Software versus services.
Downloaded or locally executed software can be a product with digital elements. A web application accessed exclusively through a browser is generally not a product with digital elements on that basis alone. However, a cloud or back-end function may form part of a product as a remote data processing solution when the product cannot perform one of its functions without it and the software was designed by, or under the responsibility of, the manufacturer.
2. Product boundaries and integrations.
A manufacturer must assess the complete product it places on the market, including integrated components, required cloud functions and relevant external dependencies. Third-party SaaS is not automatically part of the manufacturer's own remote processing solution, but its integration risks still require assessment, mitigation and proportionate supplier due diligence.
3. Substantial modifications.
A change is substantial when it affects compliance with the CRA's essential cybersecurity requirements or changes the intended purpose covered by the original risk assessment. Even a small feature - such as persistent login, a new external interface or more detailed logging - can be substantial if it creates unassessed risk. Security updates normally are not substantial modifications when they only reduce risk and do not change the intended purpose or introduce new exposure.
4. Support periods.
The support period is not automatically five years. Five years is the minimum unless the product is genuinely expected to be used for less time. Products expected to remain in service longer must generally receive vulnerability handling for that longer expected lifetime. That is highly relevant to physical access infrastructure, which is often deployed for many years.
5. Reporting and vulnerability handling.
From 11 September 2026, manufacturers must report actively exploited vulnerabilities and severe incidents affecting the security of their products. An early warning is due within 24 hours after the manufacturer has a reasonable degree of certainty, followed by a more detailed notification within 72 hours. The duty also covers qualifying products placed on the market before the main CRA requirements start in December 2027.
Consequences for electronic key and access-control systems
Electronic key systems can contain several separate products with digital elements: smart keys, readers, programming devices, controllers, local management software, mobile apps, firmware and cloud services. Each product boundary and each manufacturer's role must be identified rather than treating the installation as one undifferentiated system.
The CRA expressly classifies identity-management and privileged-access-management software and hardware, including authentication and access-control readers, as important Class I products. Smart door locks with security functionality are also listed as Class I in the smart-home category. Whether a particular commercial or industrial electronic key, cylinder, reader or controller falls within a listed category depends on its objective core functionality and technical design; the label used in marketing is not decisive.
For manufacturers, the practical consequences include:
a documented cybersecurity risk assessment covering hardware, firmware, communications, credentials, administrative tooling and relevant back-end functions;
secure-by-default configuration, protection against unauthorised access, confidentiality and integrity controls, reduced attack surfaces and resilience against denial-of-service risks where applicable;
a software bill of materials and due diligence for third-party and open-source components as part of vulnerability governance;
coordinated vulnerability disclosure, continuous monitoring of relevant vulnerability sources, effective testing and timely security updates throughout the support period;
technical documentation, an EU declaration of conformity and CE marking;
a conformity-assessment route appropriate to the product category. For Class I products, internal control is available only when the applicable harmonised standards, common specifications or qualifying certification schemes are fully applied to the risks associated with the core functionality. Otherwise, third-party assessment is required.
Operators and asset owners are not automatically manufacturers under the CRA merely because they deploy a key system. However, an organisation that substantially modifies a product and makes the modified product available on the market can assume manufacturer obligations. Long operational lifetimes also make procurement critical: buyers should require a declared support end date, vulnerability-notification arrangements, update commitments, component transparency and a workable migration or replacement path.
Consequences for IGA systems
Identity Governance and Administration systems sit close to the centre of the CRA. Identity-management systems are explicitly listed as important Class I products. This does not mean that every IGA service is automatically covered in the same way.
A locally installed IGA application, appliance, agent or connector that is commercially supplied in the EU is likely to be a product with digital elements. A browser-only SaaS service, considered by itself, is generally outside the CRA's product definition. But if a local product needs manufacturer-designed remote processing for provisioning, authentication, policy evaluation, synchronisation or updates, that remote functionality can become part of the regulated product.
IGA manufacturers should consequently define their architecture and product boundary with precision. Their CRA risk assessment should cover at least:
authentication, privileged administration and separation of duties;
joiner, mover and leaver workflows and the risk of stale or excessive privileges;
provisioning connectors, APIs, tokens, service accounts and secrets;
integrity and availability of identity and entitlement data;
audit-log confidentiality, integrity, retention and export;
tenant isolation and remote-processing dependencies;
third-party libraries, identity providers and connected target systems; and
secure upgrade, rollback and recovery processes.
The new guidance also affects product roadmaps. Adding a new control capability, authentication flow, AI-driven decision function, externally reachable API or third-party dependency can change the threat model. If the risk was not anticipated and addressed in the original assessment, the release may become a substantial modification and therefore a new placing on the market requiring an updated conformity assessment.
What this means for the Key2XS platform
Key2XS connects identity and policy to electronic keys and physical access. Publicly described platform capabilities include IGA synchronisation, approval flows, key assignment, real-time status updates, audit trails and integration with electronic key systems. That positioning makes CRA readiness strategically relevant even where the final legal classification depends on the precise deployment architecture.
The CRA relevance of the Key2XS platform can be considered at three levels.
1. The product boundary.
A browser-only service is generally not, by itself, a product with digital elements. Any Key2XS connector, agent, gateway, appliance, mobile app or packaged client supplied for execution in a customer's environment may be. Manufacturer-designed cloud functions required by such a local component may qualify as its remote data processing solution. The resulting CRA scope can therefore differ between deployment models.
2. The core functionality.
Because Key2XS governs identity-linked physical access and synchronises access rights with key systems, a supplied software product may objectively have the core functionality of identity or access management. If so, the important Class I regime may apply. The final classification depends on the technical description, intended purpose and applicable EU product-category specifications rather than branding alone.
3. The integration chain.
Key2XS does not need to manufacture every connected IGA or electronic key product to have CRA responsibilities for its own product. Those responsibilities include risks created by integrations and external dependencies. Relevant scenarios include compromised IGA events, connector credentials, replayed provisioning messages, inconsistent revocation, unavailable vendor APIs, manipulated audit data and unsafe fallback behaviour. Supplier evidence such as relevant CRA declarations, NIS2 assurance, European cybersecurity certification and ISO/IEC 27001 or 27017 can support due diligence, but does not replace a product-level risk assessment.
From compliance burden to trust infrastructure
The CRA is product legislation, while NIS2 and the Critical Entities Resilience Directive focus more directly on organisational and operational resilience. For critical organisations, these regimes reinforce each other. CRA-compliant products provide better lifecycle security and evidence; governed identity-linked physical access supports the operator's own risk management, access control, incident response and audit obligations.
Within this landscape, Key2XS translates digital identity policy into controlled physical access, with traceable issuance, timely revocation and an auditable chain across IGA and key systems. The CRA adds product-lifecycle cybersecurity and conformity requirements to the regulatory context in which these capabilities operate.
The Commission's guidance does not remove every borderline question and is not legally binding. It does, however, provide a clearer framework for determining product boundaries, support commitments, vulnerability-reporting responsibilities and the treatment of integrated systems.
Sources: https://digital-strategy.ec.europa.eu/en/library/commission-publishes-new-guidance-support-timely-cyber-resilience-act-implementation ; https://eur-lex.europa.eu/eli/reg/2024/2847/oj
*This article provides a general operational analysis and is not legal advice. Product classification should be validated for each concrete architecture and commercial model.