How the CRA Treats Identity Management Software

Identity Management Is an Annex III Class I Category

Identity management systems and privileged access management software and hardware appear in Annex III Class I. That does not mean every product containing a login screen or user account system becomes an important product. Article 7 applies the important-product classification where the product with digital elements has the core functionality of the listed category. A manufacturer should therefore begin with the supplied product and ask whether authentication, authorisation, identity-credential lifecycle management or access management defines what the product principally does. Where identity functionality merely supports another product, the host product still requires its own core-functionality assessment. The category is nevertheless deliberately broad because identity systems can control access to digital resources, physical locations, IT systems, operational technology and sensitive information.

• The category is in Annex III Class I.
• Core functionality determines classification.
• An ordinary login capability does not automatically classify the host product.
• Both digital and physical access-management products can be relevant.

The Technical Description Covers Authentication and Authorisation

Commission Implementing Regulation (EU) 2025/2392 provides the detailed technical description. Identity management systems are described as products with digital elements that provide mechanisms for authentication or authorisation. Authentication concerns establishing or verifying an identity or credential, while authorisation concerns determining what an authenticated person, organisation, device or system is permitted to access or perform. A product can provide one or both functions and still require analysis against the category. The manufacturer should document the actual identity and access decisions performed by the product rather than rely on labels such as IAM, access platform or security gateway. Products with broad administrative functions should identify whether identity and access control are central to the supplied product or merely one feature among many.

• Authentication mechanisms are expressly relevant.
• Authorisation mechanisms are expressly relevant.
• The product name does not determine the classification.
• Document the actual identity and access functions.

Identity Credential Lifecycle Management Is Also Included

The technical description also covers systems that provide mechanisms for the lifecycle management of identity credentials belonging to natural persons, legal persons, devices or systems. The implementing regulation gives examples of lifecycle activities including identity registration, provisioning, maintenance and deregistration. This means the category extends beyond the moment when a user signs in. A product can manage creation, assignment, updating, suspension or removal of identities and credentials across their lifecycle. Device and machine identities can also be relevant, so the category is not limited to human workforce accounts. Manufacturers should map which identity objects their product manages, which credential operations it performs and whether those functions constitute the product's core functionality.

• Natural-person identities can be covered.
• Legal-person identities can be covered.
• Device and system identities can be covered.
• Registration, provisioning, maintenance and deregistration are relevant lifecycle activities.

Privileged Access Management Is Expressly Included

Privileged access management is specifically included in the Class I category. The implementing regulation describes privileged access management software as an access management system that controls and monitors access rights to IT or OT systems and sensitive information within an organisation, including systems that enforce differentiated access-control policies for privileged users. This captures products designed around administrator, root, service, operational or other elevated-access accounts where controlling privileged rights is a defining function. PAM products can therefore fall squarely within Class I even where their implementation differs from conventional identity directories. The manufacturer should document which privileged identities, systems and resources the product controls and how those functions relate to its intended purpose.

The Category Includes Several Authentication Product Types

The 2025 technical description includes a non-exhaustive set of examples. These include authentication and access-control readers, biometric readers, single sign-on software, federated identity management software, one-time-password software, hardware authentication devices such as transaction authentication number generators, authentication software and multi-factor-authentication software. The examples show that the category reaches both software and hardware forms of identity and authentication technology. They should not be treated as a closed product list. A product not named in the examples can still match if its core functionality meets the technical description, while a larger product containing one of these mechanisms does not automatically become Class I solely because that mechanism is integrated.

• Single sign-on software is an example.
• Federated identity management software is an example.
• OTP and MFA software are examples.
• Hardware authentication and biometric readers can also be included.

Integrated Identity Features Need a Separate Host-Product Analysis

Many applications contain authentication, role-based permissions, single sign-on integration or local account administration. Those functions can be important to the security of the application without making identity management the application's core functionality. Article 7 specifically prevents automatic reclassification merely because a listed important product is integrated into another product. A manufacturer should therefore distinguish an identity-management product from an application that uses identity controls in support of another principal purpose. The analysis should identify whether the product itself manages identities and access for other resources, devices, systems or locations, or whether it simply authenticates users to its own primary functionality. This distinction should be preserved in the classification record.

• Do not classify from the presence of a login screen.
• Separate supporting authentication from identity-management core functionality.
• Assess the complete supplied product.
• Document integration and product-boundary reasoning.

Class I Status Changes the Conformity Assessment Decision

Where an identity management product is classified as Class I, Article 32(2) applies. Class I does not automatically require third-party assessment in every case, but internal control remains available only where the relevant Article 32 conditions are satisfied. The manufacturer needs to consider applicable harmonised standards, common specifications and available European cybersecurity certification schemes and determine whether the conditions for the internal-control route are met. Where they are not met, the product and the manufacturer's processes move to a stricter conformity procedure involving EU-type examination followed by conformity to type or full quality assurance. Classification should therefore happen early enough to influence standards mapping, evidence planning and notified-body scheduling.

• Identity management products in this category are Class I.
• Class I internal control is conditional.
• Standards coverage can affect the conformity route.
• Third-party assessment may become necessary.

Build the Classification Around the Actual Identity Product

A useful classification record should identify the product and version, intended purpose, identity subjects managed, authentication and authorisation functions, credential-lifecycle functions, privileged-access functions and any physical-access functionality. It should reference Annex III Class I category 1 and the corresponding description in Commission Implementing Regulation (EU) 2025/2392. The record should also explain whether identity capabilities are the product's core functionality or are integrated into another product with a different purpose. Once Class I status is established, the manufacturer can connect the record to the cybersecurity risk assessment, Annex I control mapping, technical documentation and Article 32 conformity procedure. Significant changes to product purpose or identity functions should trigger classification review.

• Identify the exact product and version.
• Map authentication and authorisation functions.
• Map credential-lifecycle and privileged-access functions.
• Document why identity management is or is not core functionality.
• Record the Article 32 conformity route.
• Review after material functionality changes.