Keycloak: Identity & Access Management for GDPR and NIS-2

TL;DR

• Keycloak is a mature open-source Identity & Access Management (IAM) solution that supports modern protocols like OAuth2, OpenID Connect (OIDC), and SAML 2.0, and integrates well into cloud-native architectures.
• For GDPR (particularly Article 32), NIS-2, and DORA, Keycloak provides essential components: strong authentication (MFA), granular role and permission management (RBAC), and detailed audit logs.
• In practice, Keycloak serves as a central identity provider for the Kubernetes-API, for unified MFA policies, and for consistent role concepts across infrastructure and application layers.
• By integrating into a central platform like the ayedo SDP, Keycloak becomes a strategic IAM component of your compliance architecture—with standardized operational processes, high availability, and well-documented access paths.
• ayedo supports the architecture, introduction, and operation of Keycloak, integrates the IAM into your platform and security landscape, and helps pragmatically implement regulatory requirements—from the initial assessment to productive Keycloak integration.

Why Identity & Access Management is the Core of Modern Compliance

Anyone responsible for a digital organization today knows: The major European regulatory frameworks—GDPR, NIS-2, DORA—do not target individual tools but structured security and risk management. Access to systems and data is at the center.

On May 25, 2018, the GDPR came into force, redefining the protection of personal data in Europe. On January 16, 2023, the NIS-2 Directive (EU) 2022/2555 became effective, which must be transposed into national law by October 17, 2024, and then particularly obliges critical and important entities. Also on January 16, 2023, the DORA Regulation (EU) 2022/2554 came into force; it applies from January 17, 2025, binding for financial companies and essential service providers in the financial sector.

All these regulations share a common theme: Without control over access, no reliable compliance can be demonstrated.

Identity & Access Management (IAM) is therefore not a peripheral issue but the technical manifestation of governance decisions:

• Who can do what, where, and for how long?
• How do we ensure that accesses are traceable and revocable?
• How do we implement central security policies in a decentralized, cloud-native landscape?

Keycloak addresses this core directly—offering an open, well-integrated IAM solution that seamlessly fits into modern platforms and particularly into Kubernetes-based environments.

Keycloak Overview: Open IAM for Modern Architectures

Keycloak is an open-source IAM project that has been used productively in large organizations for years. The focus is on Single Sign-On (SSO), access control, and centralized user management across applications and infrastructure levels.

Protocols: OAuth2, OIDC, SAML 2.0

Keycloak supports common standards:

• OAuth2 as an authorization framework for delegated access (e.g., services acting on behalf of a user).
• OpenID Connect (OIDC) as an identity layer over OAuth2 for modern web and API scenarios.
• SAML 2.0 for legacy or enterprise applications not yet migrated to OIDC.

This allows different applications—from modern microservices to established line-of-business systems—to connect to a central IAM without maintaining special protocols.

Central IAM Concepts in Keycloak

Some core concepts are particularly important from a compliance perspective:

• Realms: Logical security domains, such as per organization, tenant, or environment (e.g., “Production”, “Staging”).
• Clients: Applications or services that handle authentication/authorization through Keycloak.
• Roles and Groups: Mapping organizational and technical responsibilities, foundation for RBAC.
• User Federation: Connecting existing directory services (e.g., LDAP, Active Directory) to avoid maintaining parallel user inventories.
• Identity Brokering: Integrating external identity providers (e.g., corporate SSO, external partners) without sacrificing central policies.

In sum, a consistent picture emerges: Identities, roles, and policies are centrally defined and carried into the system landscape through protocol standards.

Regulatory Requirements: GDPR, NIS-2, DORA

GDPR: Protecting Personal Data Through Strong Access Controls

The GDPR requires in Article 32 “appropriate technical and organizational measures” to ensure a level of security appropriate to the risk. Explicitly mentioned are:

• Pseudonymization and encryption,
• Ensuring the confidentiality, integrity, availability, and resilience of systems,
• Procedures for regular testing, assessment, and evaluation.

IAM is a central component here: Without reliable control over who has access to personal data, confidentiality cannot be demonstrated. Keycloak directly supports:

• Enforcement of strong authentication (including MFA),
• Structured role and permission assignment,
• Traceability of login and administrative actions.

Thus, Keycloak becomes an important element of a GDPR-oriented security architecture—even though it is, of course, only part of the overall picture.

NIS-2: Critical and Important Entities Under Pressure

NIS-2 addresses the security of network and information systems, particularly in critical and important sectors (energy, health, transport, digital infrastructure, etc.). It requires:

• Strong access controls and identity management,
• Use of multi-factor authentication,
• Clear processes for permission management,
• Logging of security-relevant events.

Keycloak contributes mainly to two focal points:

1. Access Control: Role-based, centrally managed access to critical systems and management interfaces.
2. MFA: Enforcement of multi-factor authentication for administrators and sensitive applications, independent of the target application.

For organizations subject to NIS-2, a central IAM layer offers a clear advantage: Security measures do not need to be implemented individually in each system but are defined in Keycloak and consistently rolled out.

DORA: Resilience in the Financial Sector

The DORA regulation targets digital operational resilience in the financial sector and critical ICT service providers. From January 17, 2025, DORA requires:

• Clear governance structures for ICT risks,
• Robust access controls and permission processes,
• Uniform security standards for critical ICT service providers,
• Traceability and documentation of security-relevant processes.

Keycloak supports DORA requirements in two dimensions:

• Operational: Centralized user management, standardized authentication procedures, consistent RBAC for critical systems.
• Traceable: Audit and admin logs that can be integrated into SIEM or GRC systems, thus supporting documentation obligations.

Especially for regulated financial companies, a unified IAM layer is a crucial lever to integrate the multitude of systems into a consistent, auditable security architecture.

Compliance-Relevant Features of Keycloak

Multi-Factor Authentication (MFA) as Standard

Keycloak offers:

• Support for one-time passwords (TOTP),
• Hardware tokens and WebAuthn/FIDO2,
• Configurable authentication flows (e.g., MFA only for sensitive clients or admin roles).

For GDPR Article 32, MFA is a classic example of an “appropriate technical measure.” NIS-2 explicitly requires multi-factor authentication for critical accesses. DORA expects robust mechanisms, especially for privileged accounts.

By centralizing in Keycloak, MFA policies do not need to be implemented per application. Instead, the policy is defined once in the IAM and becomes effective for all connected systems.

Role-Based Access Control (RBAC)

Keycloak enables role-based authorization both at the realm and client levels. Typical patterns:

• Roles for business responsibility (e.g., “Data Owner Customer Data”),
• Roles for technical responsibility (e.g., “Cluster Admin”, “ReadOnly Operator”),
• Assignment via groups to simplify management.

In the context of NIS-2 and DORA, this is essential:
The principle of least privilege can be concretely implemented, documented, and regularly reviewed. Recertification processes can build on the roles maintained in Keycloak.

Audit and Admin Logs for Traceability

Keycloak provides detailed logging:

• Login/Logout events, failed login attempts, lockouts,
• Admin events, such as changes to roles, clients, or users,
• Integration possibilities with SIEM and log platforms.

For GDPR, NIS-2, and DORA, the ability to reconstruct security-relevant processes is central. Keycloak provides the IAM-side data foundation on which further monitoring and reporting processes can build.

Practical Application Scenarios in Cloud-Native Environments

Keycloak as Identity Provider for the Kubernetes API

The Kubernetes-API is the nerve center of modern platforms—access is correspondingly critical. In many organizations, there is historically a mix of static certificates, service accounts, and local users at the cluster level.

With Keycloak as the central identity provider for Kubernetes, the following goals can be achieved:

• Central User Identities: Developers, ops teams, and external partners use their familiar corporate accounts to access Kubernetes.
• Single Sign-On: A consistent login experience across clusters, including MFA.
• Role Mapping: Roles and groups from Keycloak can be mapped to Kubernetes roles. This makes it clear which organizational role has which technical rights in the cluster.

From an audit perspective, it is particularly valuable: Accesses to Kubernetes are directly linked to a centrally managed identity and not to anonymous certificates.

Centralized MFA for Developer and Ops Teams

In practice, there are often many admin interfaces and portals: Git servers, CI/CD pipelines, monitoring tools, cloud provider consoles, internal admin UIs. If each solution brings its own MFA logic or lacks it altogether, a heterogeneous and hard-to-audit security situation arises.

Keycloak allows:

• Uniform MFA policies across all connected systems,
• Differentiated policies (e.g., stricter MFA for production access than for test environments),
• Phased introduction (e.g., initially only for administrators, later for all productive systems).

Thus, MFA does not become a patchwork but a clearly managed part of the security architecture—in line with regulatory requirements.

Thinking RBAC Across System Boundaries

A common break in practice:
On the application level, well-thought-out role models exist, while on the infrastructure and management level, historically grown “admin” accounts without clear differentiation prevail.

Keycloak enables consistent thinking of role models:

• Professionally