Open source customer identity for the EU CRA

Why the CRA's unauthorized access requirement reaches your customer login

If your product has user accounts and is sold in the EU, the Cyber Resilience Act's unauthorized access requirement reaches your customer login. Annex I Part I point (2)(d) requires products to ensure protection from unauthorized access by appropriate control mechanisms, including authentication and identity or access management systems, and to report on possible unauthorized access. Point (2)(b) requires a secure-by-default configuration and the possibility to reset the product to its original state. The regulation applies from 11 December 2027, but the Article 14 reporting obligations already apply from 11 September 2026, so manufacturers placing products on the market now should plan for both dates.

The short answer is that a self-hosted Keycloak or ZITADEL can supply the authentication, MFA, passkey and session mechanisms that point (2)(d) describes, but it does not discharge your obligations. The manufacturer still owns the configuration the product ships with, the risk assessment under Article 13(2), and the technical documentation that must explain how the requirement is implemented or why it does not apply (Article 13(3) and (4)). Commission CRA FAQ 4.2.4 is explicit that, for a component placed on the market separately, the obligation covers the configuration it is delivered with, not later changes made by the integrating manufacturer. Confirm with your counsel and notified body which role your identity component plays in your product.

Identity management systems and privileged access management products are themselves class I important products under Annex III point 1, so a product whose core function is access control faces stricter conformity assessment. Before you choose a platform, confirm which class your product falls into, whether harmonized standards will be applied in full, and whether a notified body is needed. Then document the default realm settings, client configurations, password and passkey policies and admin access paths you ship, along with the reset procedure described in Annex II point 8(a). The Commission's CRA page and the EUR-Lex text of the regulation are the primary sources for these obligations.

Mapping CRA Annex I requirements to identity configuration

This table maps the CRA access control, secure-by-default, commissioning instruction and risk documentation requirements to specific Keycloak or ZITADEL settings. Read each row as a question to answer in your own risk assessment and technical file, and note that the obligation covers only the configuration you ship with a separately placed component.

Requirement	What the function must do	How to configure Keycloak or ZITADEL
Annex I Part I point (2)(d): protection from unauthorized access	Apply appropriate control mechanisms such as authentication and identity or access management, and report possible unauthorized access.	Use one realm per product environment in Keycloak or one instance per tenant in ZITADEL. Require MFA or passkeys for administrative and privileged accounts, enable brute-force detection, and forward authentication and admin events to your reporting pipeline.
Annex I Part I point (2)(d): authentication strength	Match authentication strength to the risk identified in your Article 13(2) assessment, including for user accounts that reach sensitive functions.	Enable WebAuthn or passkey login with password fallback where needed. Confirm with your assessor which factors your risk assessment treats as sufficient for admin and high-impact actions.
Annex I Part I point (2)(b): secure by default	Ship the product with insecure options disabled, such as weak algorithms, unvalidated certificates or open interfaces.	Disable direct access grants and implicit flows for new clients, require PKCE, restrict redirect URIs to exact values, and turn off self-registration unless the product needs it. Document each default you changed.
Annex I Part I point (2)(b): reset to original state	Allow the product to be reset to its original state, unless the manufacturer and business user agree otherwise for a tailor-made product.	Keep realm or instance configuration as versioned exports (realm JSON or Terraform or Helm definitions) so a known baseline can be reapplied. Test the reset procedure on a copy before release.
Admin console exposure	Limit administrative interfaces so that unauthorized access cannot reach configuration or user data.	Place the admin console on a separate hostname or internal network path, restrict it by address, and require strong authentication for administrators. Confirm the exact hostname settings for your chosen version in the production configuration guide.
Annex II point 8(a): commissioning and lifetime instructions	Describe the measures needed at initial commissioning and throughout the product lifetime to ensure secure use.	Write a commissioning checklist covering realm or instance creation, admin account creation, MFA enrollment, client registration and secret rotation. Add a schedule for patch review, since Keycloak plans four minor releases a year.
Article 13(2) to (4): risk assessment and technical documentation	Base the requirement on a documented risk assessment, explain how it is implemented in the technical documentation, or justify why it does not apply.	Map each identity control to a risk entry, such as credential stuffing or privilege escalation. Where a control is not applied, record the justification and the residual risk in the technical file.
Separately placed components (FAQ 4.2.4)	The obligation covers only the configuration the component is delivered with, not later changes made by the integrating manufacturer.	If you ship Keycloak or ZITADEL as a component, deliver secure settings as the default and document every setting the integrator must change. Confirm with counsel how the Commission guidance applies to your product type.
Audit events for reporting	Record authentication, administrative and configuration events so that possible unauthorized access can be detected and reported.	Enable admin and login event logging, export it to a central store, and test that alerts reach the team that handles CRA reporting. Confirm retention periods against your own obligations.

Keycloak or ZITADEL: which fits which product

Keycloak is an Apache-2.0 identity and access management server that supports OpenID Connect, OAuth 2.0 and SAML 2.0, with single sign-on, identity brokering, LDAP and Active Directory user federation, an admin console and clustering. It is a Cloud Native Computing Foundation incubation project, and its current release listed in the supplied facts is 26.8.1. For Kubernetes estates, the Keycloak Operator is installed through Operator Lifecycle Manager, the recommended method, and manages Keycloak, KeycloakRealmImport, KeycloakOIDCClient and KeycloakSAMLClient resources.

Production database: Supported databases include PostgreSQL (14 to 18), MariaDB, MySQL, Microsoft SQL Server, Oracle Database, Amazon Aurora PostgreSQL and Azure SQL. The default dev-file database is for development only.
High availability: Keycloak documents a single cluster optionally spread across availability zones, multi-cluster v2 without external Infinispan, and the deprecated multi-cluster v1. Both supported designs need a synchronously replicated database.
Operator updates: The Operator documentation strongly recommends manual approval mode to avoid unintended automatic upgrades.
Schema migration: Migrations run automatically at startup by default, with manual SQL migration available for large deployments.
Enterprise support: Red Hat build of Keycloak is a supported distribution based on the open source project.

Confirm the Keycloak version, operator approach and database platform against your own support policy before you commit to a design.

Platforms that fit a CRA access control design

The Cyber Resilience Act expects products to resist unauthorized access through authentication and identity management, and the same expectation applies to the identity platform you build on. The cards below cover the open-source options that fit that role, from the customer login layer to the governance and key storage behind it, with the license and the checks each one needs before you commit.

Keycloak for customer login

Keycloak is licensed under Apache-2.0 and supports OpenID Connect, OAuth 2.0 and SAML 2.0, which covers the authentication layer most CRA-scoped products need. Its secure-by-default posture depends on your realm settings, so review brute-force protection, redirect URI rules, token lifetimes and required MFA before go-live. Confirm your database choice and high availability design, since both supported clustered designs require a synchronously replicated database. Current release: 26.8.1.

ZITADEL for multi-tenant products

ZITADEL is licensed under AGPL-3.0 and includes passkeys based on FIDO2 and WebAuthn, SCIM v2 provisioning and tenant isolation through instances and organizations. It suits products that sell to other businesses and must keep each customer's users and identity provider separate. Confirm that AGPL-3.0 terms work for your distribution model and that PostgreSQL 14 to 18 fits your database standards. Current release: v4.19.5.

Ory Kratos with Hydra

Ory Kratos handles identity and user management, while Ory Hydra acts as the OAuth 2.0 and OpenID Connect server, and both are licensed under Apache-2.0. The split suits teams that want to build their own login experience and token service in code they control. Confirm that your engineering team can own the login flows, account recovery and session handling that Kratos leaves to the integrator, and plan how you will document those controls as technical documentation under the CRA.

authentik for flexible federation

authentik is licensed under MIT, except the authentik/enterprise directory, which carries a separate enterprise license. Check which features you need before you rely on them, because some capabilities may sit in the enterprise directory. It is a fit when you want a self-hosted identity provider with flexible federation and a visual flow designer. Confirm exactly which components your product ships, and keep the enterprise license terms in your third-party software record.

midPoint for access reviews

midPoint is an identity governance platform licensed under the European Union Public License 1.2 or later. Where access must be reviewed, approved and removed on a documented cycle, midPoint records who holds which entitlements and why. Its 4.8 Curie long-term support release is supported until October 17, 2028, so confirm that your upgrade plan targets a supported line. Use it alongside, not instead of, the login platform, and confirm which source systems feed it.

OpenBao for keys and secrets

OpenBao stores and distributes secrets, certificates and keys and is licensed under MPL-2.0 under the OpenSSF. In a CRA design it protects the signing keys, client secrets and database credentials that the identity platform depends on, so that a leaked configuration file does not grant access. Confirm how keys are rotated, who can unseal the store, and how access to the store is logged. Current release: v2.7.1.

How a product's login flow maps to the CRA configuration baseline

Under Annex I Part I point (2)(d), the manufacturer must protect the product from unauthorized access through authentication and identity or access management controls. When a connected product uses Keycloak or ZITADEL, that protection depends on three hops that the manufacturer owns: the browser or device reaching the identity provider, the identity provider issuing tokens, and the product's resource server validating them. Map each hop in the technical documentation, and record which settings apply at each one. Keycloak handles these flows through realms, clients and token settings, and ZITADEL through instances, projects and applications. Whichever product you ship, the authorization code flow with PKCE should be the only browser login path you document, and the resource server should verify token signature, issuer, audience and expiry rather than trusting the front end.

The secure-by-default settings live in the identity provider's configuration, and the manufacturer decides what the business user receives. Review access token lifetimes, exact redirect URI matching for every registered client, password and passkey policy, and the first-start administrator credentials. The default administrator must not be a shared or well-known account, and the product should force a credential change or a one-time setup before exposing the admin console. Because the Commission FAQ 4.2.4 limits the obligation for separately placed components to the configuration the component is delivered with, your shipped realm export, Helm values or operator custom resources are the evidence. Confirm with your assessor and notified body how they will treat a product that bundles the identity provider. Keycloak's Keycloak documentation lists the admin-facing settings to check.

Annex II point 8(a) requires the user instructions to describe the measures needed at commissioning and throughout the product's lifetime. Put the configuration baseline into that document as a short checklist the business user can verify: which admin account to rename or disable, how to rotate client secrets, how to restore the product to its original state, and which settings change if the customer adds its own identity provider. Keep the upgrade path in the same instructions. Keycloak's minor releases can change defaults only as opt-in changes, so note which release you tested against and what the business user must re-check after an upgrade. Each setting you ship should trace to an Article 13(3) entry or a documented justification under Article 13(4), so the assessment file shows the baseline and the reasoning behind it.

Setting a secure-by-default identity baseline before release

This sequence turns the access control requirement into a documented, tested default configuration that ships with the product and can be restored to its original state. Each step leaves an artifact that supports the technical documentation and the conformity file.

Run the access risk assessment
The product team, security lead and a privacy or legal reviewer identify every way a user, administrator, integrator or service account can reach the product, and rate the risk of unauthorized access for each path. The Article 13(2) risk assessment drives which controls are required, so this step covers the identity-related functions in scope. It is done when each access path has a documented risk rating and a named owner, and the list is reviewed against the product's intended deployment environments.
Define the default configuration as shipped
Using the risk assessment output, the engineering lead writes down the exact identity settings the product is delivered with: realm or tenant creation defaults, password and session policies, token lifetimes, redirect URI rules, enabled protocols, and which identity providers and social logins are switched on. Settings are kept as code where the platform allows it, such as realm exports or Helm and Operator manifests, so the baseline is reproducible. It is done when the baseline can be built from version-controlled files without manual clicks.
Lock down administrative access
The security engineer disables default or shared administrator accounts, requires individual administrator identities, restricts the admin console and management endpoints to defined networks, and limits administrative roles to the minimum needed. Any bootstrap credentials are forced to change at first use or are generated at installation. It is done when a test run shows that an unauthenticated or non-administrative user cannot reach administrative functions and that every administrative action is attributable to a named identity.
Enable MFA or passkeys by default
The product owner decides which second factor or passkey option is on by default for administrators and, where the risk assessment requires it, for end users, and the engineer enables it in the default configuration. Platforms such as Keycloak and ZITADEL offer MFA and passkey features, but the team must confirm the exact options available in the release they ship. Fallback paths, such as password login or recovery codes, are configured deliberately and recorded. It is done when a clean installation requires the chosen factor for the in-scope accounts and the fallback behavior is documented.
Build the reset to original state
The engineering team creates a documented procedure and tooling that returns the identity component to its shipped configuration, separate from customer data that must be kept. The team defines what is reset, what is preserved, and who may trigger the reset, and it tests the procedure against a deliberately altered installation. It is done when the reset produces the same configuration hash or export as the original baseline and the test results are stored with the release record.
Document each setting in the technical documentation
The technical writer and security lead record every default identity setting, the reason for it, and the risk assessment item it addresses in the technical documentation. Where a related requirement is not applied, the file gives the justification. User instructions describe the steps the customer must take at commissioning and during the product's lifetime, such as changing bootstrap settings or configuring identity providers. It is done when a reviewer can trace each setting from the risk assessment to the documented configuration and the instructions.
Test the baseline in staging before each release
Before each release, the QA and security team installs the product from the release artifacts into a staging environment that matches the supported deployment model, then runs authentication, MFA, administrative access and reset tests against the documented baseline. Any drift between the shipped configuration and the documentation is fixed before release. It is done when the test report shows no unexplained differences and the signed-off baseline is attached to the release.

Evidence the conformity file needs for access control

This table lists the evidence items a manufacturer should expect to assemble for the access control requirement, what each item shows an assessor, and which component usually produces it. DeployOpen prepares this evidence from the implementation, but independent conformity assessment bodies and the manufacturer's own legal review decide whether it is sufficient. Use it as a checklist when scoping the identity platform work.

Evidence item	What it shows	Which component produces it
Risk assessment record	How the Article 13(2) risk assessment selected authentication and access control measures for the product, and why any point (2) measure was judged not applicable	Manufacturer threat model, documented with the identity platform's trust boundaries and admin paths
Technical documentation on point (2)(d)	How authentication, identity and access management, and unauthorized access reporting are implemented, with the product's own configuration and integration points named	Keycloak or ZITADEL deployment design, realm or instance configuration, and the integrating product's login flows
Technical documentation on point (2)(b)	The secure-by-default configuration shipped with the product and the documented way to reset it to its original state	Exported realm or instance defaults, reset procedure and the baseline shipped with the product
Configuration baselines exported as code	The authentication settings, client registrations, password and MFA policies, and token lifetimes as they were delivered, with change history	Infrastructure-as-code repository, Keycloak Operator custom resources or ZITADEL configuration files under version control
Test results for authentication and brute-force defenses	That login throttling, lockout, MFA enforcement and token validation behave as documented in the delivered configuration	Security test reports from application and API testing against the identity endpoints
Audit event samples	That authentication successes, failures, account changes and administrative actions are recorded and can feed unauthorized access reporting	Keycloak event and admin event logs, ZITADEL audit records, forwarded to a log platform
Vulnerability handling records under Annex I Part II	How identity platform vulnerabilities are received, tracked, patched and disclosed, and how security updates reach the deployed product	Vulnerability tracking system, upgrade records and advisory handling process
User instructions under Annex II point 8(a)	The measures needed at commissioning and through the product's lifetime to keep access control secure, such as initial admin setup and upgrade steps	Operator runbooks written for the integrating manufacturer's customers and support teams

What does it cost and take to meet CRA access control with Keycloak or ZITADEL?

What drives the cost of meeting CRA access control with Keycloak or ZITADEL?

The main cost drivers are the scope of your products that rely on the identity platform, the number of user populations and tenants, the depth of customization in login flows, and the amount of evidence you must produce for the risk assessment and technical documentation. The software licenses for Keycloak (Apache-2.0) and the core of ZITADEL (AGPL-3.0) carry no per-user fee for self-hosting, so the spend is mainly infrastructure you run, the people who configure and operate it, and any external assessment you choose to buy. Ask any implementation partner for a fixed-scope quote that lists each product, each identity flow, each environment, and each deliverable, because those items determine the work more than the platform choice does.

When do the CRA dates require access control to be in place?

The regulation applies from 11 December 2027, so products placed on the EU market before that date fall under it only if they are substantially modified from that date. Separately, the Article 14 reporting obligations apply from 11 September 2026, and they apply to in-scope products whenever they were placed on the market. The practical planning point is that any product you release or substantially change after 11 December 2027 needs its authentication and identity controls designed, documented and evidenced, and the reporting process must work now if you already ship in-scope products. Confirm your product's status with your legal or compliance team, since the timing depends on the product's placement history and modifications.

Does an identity product like Keycloak or ZITADEL need a notified body under Annex III?

Identity management systems and privileged access management software are themselves class I important products under Annex III, point 1, so a product whose core function is access control faces stricter conformity assessment than most products. A notified body is needed for class I important products where harmonized standards, common specifications or certification schemes are not applied in full. Most products otherwise follow self-assessment under module A. Whether this applies to your product depends on whether you build a product whose core function is identity or access control, and on whether you apply the harmonized standards in full, which is a question to settle with your conformity assessment advisor before you commit to a route.

What must the manufacturer provide to show access control is in place?

The manufacturer must show how the protection from unauthorized access is implemented, based on the Article 13(2) risk assessment, and the technical documentation must explain how it is implemented or justify why it does not apply. You also need user instructions that describe the measures required at initial commissioning and throughout the product's lifetime to keep use secure. In practice that means a documented authentication and access model, configuration records for the identity platform, evidence of secure-by-default settings such as the state a product ships in and how it can be reset, and a reporting process for possible unauthorized access. Ask your partner to map each of these items to a named artifact before work starts.

Can our team implement CRA access control with Keycloak or ZITADEL alone?

A capable team can do much of the work alone if it already runs identity systems in production, understands the CRA requirements, and has time to document the evidence. The work that often needs outside help is the independent review of the risk assessment, the hardening of the deployment, the upgrade and backup routines, and the technical documentation that a conformity assessment will test. DeployOpen plans, implements, hardens, documents and supports self-hosted open-source platforms inside the client's own infrastructure, and most engagements are fixed-scope with the deliverables agreed in writing. DeployOpen does not issue audit reports or certifications, so independent auditors or certification bodies still make the formal determination.

How do Keycloak upgrades and ZITADEL licensing affect ongoing CRA work?

For Keycloak, the project plans four minor releases a year and says breaking changes in a minor release will be opt-in, so upgrades are recurring work you must schedule, test and document. The Keycloak Operator documentation strongly recommends manual approval mode for operator updates to avoid unintended automatic upgrades, and database schema migration runs automatically at startup by default unless you choose manual migration. For ZITADEL, the core, Console and hosted login moved to AGPL-3.0 with v3.0 on 31 March 2025, while APIs, SDKs, Helm charts and Terraform configurations remain Apache 2.0. Review the AGPL-3.0 obligations with your legal team before you modify and distribute those components as part of a product you sell, because they apply to what you ship. Keep each upgrade tied to a regression test and an updated configuration record so your evidence stays current.

What is the maximum fine for getting CRA access control wrong?

Article 64 sets the ceiling for breaches of Annex I and Articles 13 and 14 at EUR 15 million or 2.5% of total worldwide annual turnover, whichever is higher. Other listed obligations carry a ceiling of EUR 10 million or 2%, and incorrect or misleading information given to authorities carries EUR 5 million or 1%, again whichever is higher. Because access control sits in Annex I, a missing or unjustified control is in the highest band. These figures are maximums set by the regulation, not estimates of what an authority would impose, so confirm the applicable exposure with your legal counsel.

What identity tooling alone does not satisfy

Keycloak or ZITADEL can supply authentication and identity management for a product, but the essential requirement is assessed at the level of the whole product. The cards below cover the obligations that stay with the manufacturer, whatever identity platform is chosen, and the points where a product team most often assumes the component has already handled them.

Risk assessment and documentation stay with you

Access control is required only on the basis of the Article 13(2) risk assessment, and the technical documentation must either explain how the requirement is implemented or justify why it does not apply. A Keycloak or ZITADEL realm does not write that justification for you. Check that your assessment names the account types, admin paths, API tokens and recovery flows your product exposes, and that each one maps to a documented control.

Integrator changes fall outside the component

Commission CRA FAQ 4.2.4 limits the obligation for separately placed components to the configuration the component is delivered with. If your product team later changes realm settings, disables a secure default, or adds a custom flow, that change sits with you as the integrating manufacturer. Keep a baseline export of the hardened configuration and review every deviation against the risk assessment before release.

Vulnerability handling needs its own process

Annex I Part II sets vulnerability handling requirements that are separate from the access control requirement in Part I. Keeping Keycloak or ZITADEL current does not by itself identify, prioritize and disclose flaws in your own code, plugins, themes or SDK integrations. Assign owners for component advisories, a triage path for reports, and a record that shows how each fix reached customers.

Reporting runs on its own clock

Article 14 reporting obligations apply from 11 September 2026, and ENISA's Single Reporting Platform began accepting notifications the same day. Notifications for actively exploited vulnerabilities and severe incidents must reach the designated CSIRT, not only your help desk. Build the routing, the named reporting contacts and the escalation steps before an incident happens, because the identity platform will not make that decision for you.

Harmonized standards are still in progress

Commission standardization request M/606 asks European standardization organizations for 41 harmonized standards, and several deliverables are due after 2026. Until the relevant standards are published and applied, you may need to show how the requirements are met through other means, which can lengthen conformity work. Track the status of the standards that cover authentication and access control, and confirm with your notified body or assessor which evidence they will accept.

Unauthorized access logging must be designed in

Annex I asks the product to report on possible unauthorized access, which is a product property and not a feature of the identity server alone. Keycloak and ZITADEL emit authentication events, but your application must log failed logins, role changes, token misuse and administrator actions in a form that reaches your monitoring. Confirm which events are retained, for how long, and who receives the alerts, and test that a simulated intrusion produces a record a customer can act on.

How DeployOpen scopes and delivers CRA-ready customer identity

DeployOpen plans, implements, customizes, integrates, hardens, documents and supports self-hosted open-source identity platforms inside the client's own infrastructure. For CRA-driven customer identity, we start from the product's risk assessment and the access control evidence it needs, then build and document the Keycloak or ZITADEL configuration that the product ships with.

How we scope

Engagements are fixed-scope, with scope, deliverables and timelines agreed in writing before work starts.
We map which products, user populations and login paths fall under the access control requirement and the risk assessment behind it.
We confirm the secure-by-default settings and the reset-to-original-state approach the written scope will cover, including any tailor-made agreements with business users.

How we build

We deploy Keycloak or ZITADEL in the client's own cloud account, data center or air-gapped network, using the database and high availability design the scope calls for.
We harden the shipped configuration so deprecated options are off and authentication, MFA or passkey settings are enabled by default.
We test login, federation, account recovery and unauthorized access paths, and record the results against the agreed scope.

How we hand over

We document how each access control measure is implemented, and where a requirement is judged not to apply, the justification for that decision.
We prepare the user instructions for initial commissioning and secure use over the product's lifetime, as the written scope defines them.
We hand over runbooks, configuration records and evidence packs so the client's own team and assessors can verify the controls.

How we support

Ongoing support, upgrades and continuous testing are available as retainers, agreed separately from the initial scope.
We plan upgrades with the client, including reviewing Keycloak release notes or ZITADEL release changes before any update is applied.
We confirm with the client which compliance evidence an independent auditor or certification body will need, since DeployOpen prepares evidence but does not issue audit reports or certifications.

Open source customer identity for the EU Cyber Resilience Act