Identity Governance for EU Regulatory Compliance

Identity governance and administration (IGA) is the discipline of ensuring that the right individuals have access to the right resources at the right time for the right reasons — and that this access is continuously validated, documented, and auditable. For EU-regulated entities, IGA is not an IT operations concern; it is a regulatory compliance obligation that sits at the intersection of NIS2's access control requirements, DORA's ICT security policies, GDPR's data protection principles, and the broader expectation of supervisory authorities that organisations can demonstrate who accessed what, when, and why.

The strategic value of identity governance extends beyond compliance. A mature IGA programme reduces the attack surface by enforcing least privilege, accelerates onboarding and offboarding by automating access provisioning, reduces audit preparation effort by maintaining continuous evidence, and supports zero-trust architecture by providing the identity context that access decisions depend on. For organisations pursuing multiple EU compliance frameworks simultaneously, IGA is the foundational capability that enables multi-framework compliance without multiplicative effort — the same identity controls satisfy access control requirements across NIS2, DORA, ISO 27001, and GDPR.

The maturity spectrum of identity governance ranges from manual, reactive processes (spreadsheet-based access tracking, email-based access requests, annual review campaigns) to automated, policy-driven governance (role-based provisioning, real-time access analytics, continuous compliance monitoring). Most EU organisations operate in the lower-middle of this spectrum — they have an identity provider and some access request workflows, but lack comprehensive lifecycle automation, SoD enforcement, and non-human identity governance. The regulatory pressure from NIS2 and DORA is forcing a rapid maturity leap, and organisations that treat this as a strategic investment rather than a compliance tax will gain operational advantages that extend well beyond audit readiness.

Privileged access — administrative accounts, root access, database administrator roles, cloud IAM roles with broad permissions — represents the highest-risk category of identity entitlements. A compromised privileged account provides an attacker with the ability to move laterally, escalate privileges further, exfiltrate data, deploy ransomware, or destroy systems. NIS2 Article 21(2)(i) requires access control measures that are proportionate to risk, which necessarily means that privileged access demands stronger controls than standard user access. DORA's RTS on ICT risk management explicitly requires financial entities to implement privileged access management controls including just-in-time access, session recording, and enhanced monitoring.

Implement a privileged access management (PAM) programme built on four principles. First, minimise standing privilege: replace persistent admin accounts with just-in-time (JIT) access that is requested, approved, time-bounded, and automatically revoked upon expiration. Second, enforce multi-factor authentication for all privileged access — NIS2 Article 21(2)(j) makes MFA explicit, and privileged access without MFA is indefensible in any supervisory review. Third, monitor and record privileged sessions: maintain audit logs of all privileged actions that can be reviewed during incident investigations and access reviews. Fourth, separate privileged from unprivileged identities: administrators should use separate accounts for administrative and day-to-day activities, preventing credential theft from a compromised user workstation from yielding administrative access.

The least privilege principle — granting only the minimum access necessary to perform a specific function — is easy to state and difficult to operationalise. Start with role engineering: define standard roles for each job function that include only the entitlements required for that role's duties. Validate role definitions with business stakeholders who understand the actual workflows, not just the theoretical job descriptions. Implement request-approval workflows for any access beyond the standard role, requiring business justification and time-bounded access where possible. Use access analytics to identify entitlements that are granted but never used — these are candidates for removal from the role definition. Over time, the combination of well-defined roles, JIT access for exceptions, and analytics-driven role refinement will converge on a practical implementation of least privilege that is both operationally viable and regulatorily defensible.

Non-human identities — service accounts, API keys, machine certificates, bot accounts, and automated workflow credentials — often outnumber human identities in modern IT environments by a factor of 10:1 or more. Despite their prevalence, non-human identities are frequently excluded from identity governance programmes, creating a significant blind spot. These identities often hold elevated privileges (a CI/CD service account may have deployment access to production, a monitoring agent may have read access to all systems), and their credentials are rarely rotated, never reviewed, and not subject to the same lifecycle management controls as human identities. An attacker who compromises a service account credential gains persistent, privileged access that is unlikely to be detected by user-focused security monitoring.

Bring non-human identities into your governance programme by treating them as first-class identity objects. Every service account and API key should have an assigned owner (a human who is accountable for its security and lifecycle), a documented purpose (what the identity does and why it needs the access it has), a defined scope (minimum necessary permissions, not broad admin access for convenience), a credential rotation schedule (90 days maximum for passwords, shorter for API keys in high-risk environments), and inclusion in access review campaigns (the owner reviews whether the service account is still needed and appropriately scoped). NIS2's access control requirements apply to all identities that access network and information systems, not just human users, and supervisory authorities are increasingly aware of the risks posed by unmanaged non-human identities.

API key and secret management requires specific controls beyond traditional identity governance. Store all secrets in a dedicated secret management vault — never in source code, configuration files, environment variables in version control, or shared documents. Implement automated detection for secrets committed to code repositories. Enforce short-lived credentials where the technology supports it: OAuth 2.0 client credentials with short token lifetimes, cloud IAM instance profiles rather than long-lived access keys, and certificate-based authentication with automated renewal. When a service account or API key is decommissioned, ensure that all associated credentials are immediately revoked and that dependent systems are updated — orphaned credentials for decommissioned services are a common attack vector that access reviews should explicitly check for.