CRA Requirements for Cloud Authentication Services

Authentication Can Be a Product Function Under the CRA

A product may depend on remote authentication before users or devices can access its functions. The Commission's remote data processing guidance recognises identity and access management as functionality that can be supported remotely. Where a manufacturer-controlled authentication service is necessary for the product to operate as intended, that dependency should be tested against Article 3(2).

• Identify whether login is necessary for a product function.
• Identify the remote authentication software.
• Identify manufacturer responsibility.
• Test behaviour if authentication is unavailable.

An Authentication Portal Can Qualify as Remote Data Processing

A remote authentication portal that issues credentials or tokens required for a product with digital elements to operate can satisfy the functional-dependency limb of Article 3(2), provided the software is also designed and developed by the manufacturer or under its responsibility. The fact that authentication occurs through a browser does not automatically take that remote service outside the product where the local product depends on the resulting credentials.

• Token issuance can support a product function.
• Credential issuance can support a product function.
• Browser delivery does not automatically exclude RDPS.
• The complete Article 3(2) test still applies.

Annex I Requires Protection Against Unauthorised Access

Annex I requires products, based on the cybersecurity risk assessment and where applicable, to protect against unauthorised access through appropriate control mechanisms. The Regulation expressly mentions authentication and identity or access management systems. Product manufacturers therefore need to evaluate authentication strength, authorisation design, privileged access, credential handling and other controls according to the product's risks.

• Protect against unauthorised access.
• Use appropriate authentication.
• Use appropriate identity or access management.
• Protect privileged access.
• Select controls based on the cybersecurity risk assessment.

Authentication and Authorisation Should Not Be Treated as the Same Control

Authentication establishes or verifies identity, while authorisation determines what an authenticated user, device or service can do. A product can have strong login security and still expose excessive privileges after authentication. CRA risk analysis should therefore examine both identity assurance and permission enforcement, including server-side checks for product APIs and cloud functions.

• Verify identity appropriately.
• Enforce permissions separately.
• Apply least privilege where suitable.
• Protect administrative roles.
• Avoid relying only on client-side access controls.

Credential and Token Security Affect Product Confidentiality and Integrity

Authentication systems often process credentials, session tokens and other sensitive data. Annex I requires protection of confidentiality and integrity for stored, transmitted and otherwise processed data. Manufacturers should therefore protect authentication traffic, token storage, secrets, signing material and session state according to the risks of the product.

Authentication Availability Can Affect Product Availability

If the product cannot perform important functions when the authentication service is unavailable, the authentication layer is not only an access-control mechanism but also an availability dependency. Annex I requires protection of essential and basic functions, including after incidents, where applicable. Manufacturers should therefore evaluate authentication outages, denial-of-service exposure, recovery paths and whether safe offline behaviour is appropriate.

• Assess authentication-service outages.
• Assess denial-of-service risk.
• Design recovery procedures.
• Consider safe fallback where appropriate.
• Avoid bypassing security merely to preserve availability.

Account Recovery Is Part of the Authentication Attack Surface

Password resets, recovery links, device re-enrolment and support-assisted account recovery can become easier attack paths than the primary login process. Because Annex I requires limiting attack surfaces and protecting against unauthorised access, manufacturers should include recovery workflows in the product cybersecurity risk assessment rather than reviewing only the normal authentication path.

• Assess recovery flows.
• Protect password-reset mechanisms.
• Protect device re-enrolment.
• Restrict support-assisted recovery.
• Monitor high-risk recovery events where appropriate.

Third-Party Identity Providers Need a Separate Responsibility Analysis

A manufacturer can rely on a third-party identity provider rather than developing the authentication service itself. Where the identity service is a standard external offering designed outside the manufacturer's responsibility, the manufacturer-responsibility limb of Article 3(2) may not be satisfied for that service. The integration can nevertheless be security critical and should be included in the product risk assessment, with proportionate due diligence and product-level mitigations.

• Identify who develops the identity service.
• Identify configuration responsibility.
• Assess dependency risks.
• Perform proportionate provider due diligence.
• Implement product-level safeguards.

Third-Party Authentication Does Not Remove Product Responsibility

Using an external identity provider does not transfer responsibility for the manufacturer's product to that provider. The manufacturer still decides how authentication is integrated, which claims or tokens are trusted, what permissions they unlock and what happens during provider failures. CRA compliance therefore requires the manufacturer to assess the security of its integration even where the underlying identity service is externally supplied.

• Validate identity-provider outputs.
• Restrict trusted claims.
• Enforce product permissions.
• Handle provider outages securely.
• Monitor integration changes.

Product Authentication Is Different From Workforce Authentication

A manufacturer's corporate workforce identity platform does not automatically become part of every CRA product. Product-facing authentication should be distinguished from employee access to internal systems. Where the same identity infrastructure is reused, the product-boundary analysis should identify the software modules and interfaces that actually deliver product functionality while avoiding an unlimited extension into the manufacturer's entire enterprise network.

• Separate customer identity from employee identity.
• Identify product-facing interfaces.
• Do not automatically include the whole corporate IAM environment.
• Assess shared dependencies where they can affect product security.

Authentication Does Not Automatically Make the Whole Product Class I

Annex III Class I includes identity management systems and privileged access management software and hardware, including authentication and access-control readers. That classification rule concerns products whose core functionality matches the listed category. A broader mobile application, IoT device or other product does not automatically become a Class I identity-management product merely because authentication is one security feature or supporting function. Classification and remote-data-processing scope should therefore be analysed separately.

• Annex III includes identity-management systems.
• Core functionality controls classification.
• Authentication as a supporting feature is not enough by itself.
• Keep Article 3 scope and Article 7 classification analyses separate.

Authentication Service Changes Can Affect the CRA Risk Assessment

Authentication services frequently change through new multi-factor methods, token formats, identity providers, account recovery processes or federation relationships. These changes can alter the product's attack surface and cybersecurity risk even when the local software version does not change. Manufacturers should trigger security and documentation review for significant authentication architecture changes.

• Review new authentication methods.
• Review identity-provider changes.
• Review token changes.
• Review account-recovery changes.
• Update risk evidence where appropriate.

Maintain a Cloud Authentication Control Map

A cloud authentication control map should identify login endpoints, token issuers, identity providers, account databases, authorisation services, privileged administrative access, recovery systems and product functions dependent on authentication. For each element, record whether it is manufacturer-controlled RDPS or an external dependency and identify the corresponding security controls. This prevents important authentication dependencies from disappearing between product, cloud and enterprise teams.

• Map authentication endpoints.
• Map identity providers.
• Map token flows.
• Map authorisation decisions.
• Identify external dependencies.
• Record RDPS status.
• Review after authentication changes.