# HelixIAM Documentation > HelixIAM — the complete identity & access management platform. Enterprise SSO, strong authentication, federation and EU eIDs, on your own infrastructure. HelixIAM is a commercial identity and access management server (OAuth2 / OpenID Connect provider, SAML 2.0 IdP) from KubeDNA B.V. that you run on your own infrastructure. It ships as two images that scale independently: the server (n stateless replicas) and the admin console (helix-dashboard, its own Deployment). These docs describe release v1.1.0-rc.14, plus changes merged for the next release (the console image and Helm Deployment, the admin API restricted to the admin host, the __Host-XSRF-TOKEN cookie, console screens for every admin feature); upgrade notes: https://docs.helixiam.com/operations/upgrade-1.1.0-rc1-next/. The EU Digital Identity Wallet extensions (credentials beyond the PID, credential issuance, verified_claims, the verification API, transaction confirmation, DIDs, step-up and profile) are Preview, not yet tested with a real national wallet. Licence: proprietary. HelixIAM requires a commercial licence from KubeDNA B.V. (contact@helixiam.com); licensed customers receive registry credentials for the images and Helm chart, and the release files. Details: https://docs.helixiam.com/licensing/ - Commercial licence, demo and pricing: KubeDNA B.V., contact@helixiam.com - Upgrade notes: https://docs.helixiam.com/operations/upgrades/ - Website: https://helixiam.com/ (its own index: https://helixiam.com/llms.txt) - Full text of every page in one file: https://docs.helixiam.com/llms-full.txt Every page is available as Markdown at the URLs below (the same path as its source in the docs repository); its HTML version is the same path without `.md` (`/x/index.md` -> `/x/`, `/x/y.md` -> `/x/y/`). ## Overview - [Home](https://docs.helixiam.com/index.md): HelixIAM is the complete identity & access management platform for modern applications — a multi-tenant OpenID Connect and SAML 2.0 identity provider with strong authentication, federation, EU electronic IDs, provisioning, and a full admin & end-user console. ## Getting started - [Getting started](https://docs.helixiam.com/getting-started/index.md): HelixIAM installs on your own infrastructure. Pick a path. - [Quickstart](https://docs.helixiam.com/getting-started/quickstart.md): Three ways to run HelixIAM v1.1.0-rc.14: pick one. Each needs a HelixIAM licence: you receive registry credentials and the release files from KubeDNA B.V. (contact@helixiam.com). The commands below expect the registry user name and token in REGISTRY_USER and REGISTRY_TOKEN. - [Authenticating to the API](https://docs.helixiam.com/getting-started/api-authentication.md): Every code example in these docs talks to a running HelixIAM server. This page sets up the two things every example needs: where the server is and how to authenticate. Read it once, then copy-paste your way through the rest of the docs. - [Core concepts](https://docs.helixiam.com/getting-started/concepts.md): A small vocabulary runs through HelixIAM. Learn these and the rest of the docs read easily. - [Install](https://docs.helixiam.com/getting-started/install.md): HelixIAM ships as two images — helix-iam-server (OAuth2/OIDC/SAML + admin API, owns PostgreSQL) and the console — plus PostgreSQL and, optionally, Redis. - [Configuration](https://docs.helixiam.com/getting-started/configuration.md): Everything is environment-driven, so the same images run on a laptop or in production. The essentials. - [Architecture](https://docs.helixiam.com/getting-started/architecture.md): HelixIAM ships as two container images that are deployed and scaled independently: the server and the admin console. They are separate products: scaling one never scales the other. ## Manage - [Manage](https://docs.helixiam.com/manage/index.md): Day-to-day administration of a realm's identities and the apps that trust it. - [Realms — Overview](https://docs.helixiam.com/manage/realms.md): A realm is an isolated identity domain in HelixIAM — a self-contained tenant with its own users, applications, roles, signing keys, authentication flows, federation, and branding. - [Realms — Realm settings](https://docs.helixiam.com/operations/realm-settings.md): Tune each realm's session behaviour, branding, languages and token audiences from a single tabbed configuration page. - [Realms — Realm keys](https://docs.helixiam.com/operations/realm-keys.md): Every realm signs its tokens and its SAML assertions with its own key. You can let HelixIAM generate keys, bring your own key and certificate, or have HelixIAM create a key and a certificate signing request (CSR) for your CA — and roll over to a new key without downtime. - [Realms — Key custody (HSM / KMS)](https://docs.helixiam.com/operations/key-custody.md): Keep a realm's private signing keys out of the database: in a hardware security module (PKCS#11) or in a Vault / OpenBao Transit engine you run yourself. You choose per realm how far the keys are kept away from HelixIAM, and every request that needs an unavailable backend fails closed. - [Realms — Key custody plugins](https://docs.helixiam.com/operations/custody-plugins.md): A key custody plugin adds a backend type (a cloud KMS, a vendor HSM, a key manager of your own) to HelixIAM without changing the server. The plugin interface is public, documented and versioned; the built-in pkcs11, vault and kmip backends use the same interface. - [Realms — Login theming](https://docs.helixiam.com/operations/theming.md): White-label every realm's sign-in experience so it looks like it belongs to the tenant, not the platform. - [Realms — Notifications (SMS/email/push)](https://docs.helixiam.com/operations/notifications.md): Wire each realm to your own SMS, email and push providers, and craft the templates that carry one-time codes, magic links and alerts. - [Applications & clients — Applications](https://docs.helixiam.com/manage/applications.md): An application is a protocol-agnostic service provider — a single human-named entity that can own an OIDC client and/or a SAML relying party while sharing one subject-claim, one login flow, and one display name. - [Applications & clients — OIDC clients](https://docs.helixiam.com/manage/oidc-clients.md): An OIDC client is the OAuth2 / OpenID Connect face of an application — it defines how a relying party obtains tokens from the realm's issuer. - [Applications & clients — OIDC client settings](https://docs.helixiam.com/manage/oidc-client-settings.md): Per-client settings that go beyond the basics on OIDC clients: where a client's keys come from, what its sign-in page shows, signed userinfo, request objects by reference, session management and login initiation. They arrived with v1.1.0-rc.14, and every one is off or empty until you set it. - [Applications & clients — SAML relying parties](https://docs.helixiam.com/manage/saml-clients.md): A SAML relying party (service provider) is the SAML 2.0 face of an application — HelixIAM acts as the SAML Identity Provider issuing assertions to it. - [Applications & clients — Client scopes & claims](https://docs.helixiam.com/manage/scopes-and-claims.md): A client scope bundles a set of claims — user attributes mapped onto token fields — that a client may request and receive. - [Applications & clients — Admin console client](https://docs.helixiam.com/manage/admin-console-client.md): The Helix admin console signs in through a standard OpenID Connect client — helix-console — using the authorization code flow with PKCE, exactly like any other application you register. - [Users & access — Users & credentials](https://docs.helixiam.com/manage/users.md): Users are the accounts in a realm — their credentials, attributes, roles, and lifecycle are managed here. - [Users & access — Groups](https://docs.helixiam.com/manage/groups.md): Groups organize users into a hierarchy and grant roles in bulk — members inherit the roles mapped to their group. - [Users & access — Organizations (B2B)](https://docs.helixiam.com/manage/organizations.md): Organizations model B2B tenancy inside a realm — they group members so you can represent the companies, customers, or partners that share one realm. - [Users & access — Realm & client roles](https://docs.helixiam.com/manage/roles.md): Roles are named permissions you assign to users and groups to drive authorization decisions in your applications. - [Users & access — Admin roles (RBAC)](https://docs.helixiam.com/operations/admin-roles.md): Scope exactly what each administrator can see and do with fine-grained, role-based access control. - [Sessions](https://docs.helixiam.com/manage/sessions.md): The Sessions screen is the unified view of active identities in a realm — the people, AI agents and service accounts that currently hold a live session or token — with per-row detail and revocation. ## Authentication - [Authentication](https://docs.helixiam.com/authentication/index.md): How users prove who they are — the flow engine and the factors it can require. - [Flow editor](https://docs.helixiam.com/authentication/flows.md): Design exactly how people sign in to each realm — from a single password prompt to a multi-step, risk-aware journey — without writing code. - [Password policy & lockout](https://docs.helixiam.com/authentication/password-policy.md): Enforce strong credentials and stop credential-stuffing and brute-force attacks before they reach your applications. - [MFA — Overview](https://docs.helixiam.com/authentication/mfa.md): Raise the bar from "something you know" to "something you have" — and prove who's really signing in. - [MFA — TOTP & OTP factors](https://docs.helixiam.com/authentication/otp.md): Add a second factor your users already understand — a six-digit code or a one-tap link — backed by your own delivery channels. - [MFA — Passkeys (WebAuthn)](https://docs.helixiam.com/authentication/passkeys.md): Give users the strongest, simplest sign-in available — phishing-resistant, password-free, and backed by hardware. - [MFA — Device push & mobile app](https://docs.helixiam.com/authentication/device-push.md): Turn your users' phones into a trusted authenticator — approve a sign-in, scan to log in on a laptop, or cryptographically sign exactly what they're authorizing. - [Risk-based / adaptive](https://docs.helixiam.com/authentication/risk-based.md): Demand more proof only when something looks risky — keep everyday sign-in frictionless, and challenge harder when it counts. ## Federation & eIDs - [Federation & eIDs](https://docs.helixiam.com/federation/index.md): Delegate authentication to external identity sources — other providers, directories, social logins, and EU electronic IDs. - [Identity providers](https://docs.helixiam.com/federation/identity-providers.md): Let people sign in with an account they already have — HelixIAM brokers the login, provisions the user automatically, and keeps you in control of every attribute. - [Mappers (claims, attributes, roles)](https://docs.helixiam.com/federation/mappers.md): Turn what an identity provider sends into Helix user attributes and roles, and decide what a SAML application receives back. - [Brokers — OIDC & social brokers](https://docs.helixiam.com/federation/oidc-social.md): Let users sign in with any standard OpenID Connect provider or a social account, and have HelixIAM provision and own the resulting identity. - [Brokers — SAML broker](https://docs.helixiam.com/federation/saml.md): Broker authentication to an external SAML 2.0 identity provider, with HelixIAM acting as the service provider and owning the resulting user. - [Brokers — LDAP / Active Directory](https://docs.helixiam.com/federation/ldap.md): Federate users from your LDAP or Active Directory directory — they authenticate against the directory and appear as managed HelixIAM users. - [EU / NL eIDs — DigiD (NL citizen)](https://docs.helixiam.com/federation/digid.md): Sign in Dutch citizens with DigiD — the national citizen eID. The connector ships with HelixIAM and is configurable from the console; going live needs your own accepted DigiD connection. - [EU / NL eIDs — eHerkenning (NL business)](https://docs.helixiam.com/federation/eherkenning.md): Sign in Dutch businesses and their employees with eHerkenning — the national business eID. The connector is included; connecting to production is arranged through the scheme (see below). - [EU / NL eIDs — eIDAS (EU cross-border)](https://docs.helixiam.com/federation/eidas.md): Sign in EU citizens from across the Union with eIDAS cross-border login. The connector is included; connecting to production runs through your national eIDAS node (see below). - [EU Digital Identity Wallet — Sign-in (OpenID4VP)](https://docs.helixiam.com/federation/eudi-wallet.md): Let people sign in by presenting the PID (Person Identification Data) credential from an EU Digital Identity Wallet. HelixIAM acts as the OpenID4VP *verifier*: it asks the wallet for the PID, verifies the presentation end to end, and signs the user in to the realm. - [EU Digital Identity Wallet — Step-up and profile](https://docs.helixiam.com/federation/wallet-step-up-and-profile.md): Settings for a verify-only wallet connection that control how long a wallet step-up lasts, whether a signed-in user can step up without signing in again, whether an unlinked wallet can be bound to the user by matching profile attributes, and whether verified attributes are kept on the profile. - [EU Digital Identity Wallet — Trusted lists](https://docs.helixiam.com/federation/trusted-lists.md): A wallet connection can take its issuer trust anchors from published, signed trusted lists that HelixIAM fetches, verifies and refreshes itself, instead of (or as well as) PEM certificates you paste in. - [EU Digital Identity Wallet — Credentials beyond the PID (EAA)](https://docs.helixiam.com/federation/wallet-credentials.md): A wallet connection can ask the wallet, in the same request as the PID, for other electronic attestations of attributes ((Q)EAA): a mobile driving licence, a diploma, a professional qualification, a permit. - [EU Digital Identity Wallet — Transaction confirmation](https://docs.helixiam.com/federation/wallet-transaction-confirmation.md): An application can have a signed-in user confirm one transaction — a consent text, a payment — with their EU Digital Identity Wallet. The wallet shows the transaction and the user's wallet key signs a hash of exactly what was shown (OpenID4VP 1.0 transaction_data). - [EU Digital Identity Wallet — DIDs](https://docs.helixiam.com/federation/dids.md): Helix can accept SD-JWT VC issuers identified by decentralised identifiers (DIDs), publish a realm's own did:web document as a credential issuer, and accept DID-named holder keys in issuance proofs. (Preview, not yet tested with a real national wallet.) - [EU Digital Identity Wallet — Credential issuance (OpenID4VCI)](https://docs.helixiam.com/federation/credential-issuance.md): A realm can issue verifiable credentials about its own users to their EU Digital Identity Wallets, over OpenID for Verifiable Credential Issuance 1.0 (HAIP-aligned): SD-JWT VC (dc+sd-jwt) and ISO mdoc (mso_mdoc), each bound to a key the wallet proves, each with a Token Status List entry so it can be revoked. ## Integration - [Integration](https://docs.helixiam.com/integration/index.md): Connect your apps, machines, and agents — and automate Helix as code. - [OIDC quickstart](https://docs.helixiam.com/integration/oidc-quickstart.md): Log a user in with standards-based OpenID Connect — authorization code + PKCE — in a few HTTP calls. - [OIDC flows & claims](https://docs.helixiam.com/integration/oidc-flows.md): This page is for operators and realm administrators. It covers what the authorization endpoint of a realm (/realms//oauth2/authorize) accepts, and which claims the tokens and userinfo carry. - [CLI & native apps](https://docs.helixiam.com/integration/cli-auth.md): Give a command-line tool, desktop app, or any other native app a first-class sign-in: a browser login (authorization code + PKCE), a headless device login (RFC 8628), and a long-lived, silently-refreshed session — no secret baked into the binary. - [Agents (AI / NHI) — Agents overview](https://docs.helixiam.com/integration/agents.md): Give every AI agent, bot, and automation a first-class identity — with an accountable human owner, a lifecycle you control, and tokens that say *what* is calling and *on whose authority*. - [Agents (AI / NHI) — Authorization & scenarios](https://docs.helixiam.com/integration/agent-authorization.md): How much can a non-human identity *do*? Getting this right is the single most important security decision for AI agents and automations. Helix uses one rule everywhere, and it is deliberately not "the agent gets its owner's permissions." - [Agents (AI / NHI) — MCP authorization](https://docs.helixiam.com/integration/mcp.md): The Model Context Protocol (MCP) lets an AI agent call *tools* on a server. The MCP authorization spec builds directly on OAuth 2.1: an MCP server is just an OAuth resource server, and the agent is an OAuth client. - [Workload identity — Kubernetes / CI](https://docs.helixiam.com/integration/workload-identity.md): Give your Kubernetes pods and CI jobs a Helix identity without a client secret. A workload presents a short-lived JWT that its own platform already issues — a Kubernetes projected ServiceAccount token, a GitHub Actions or GitLab CI OIDC token — and Helix exchanges it for a Helix access token. - [Workload identity — Using workload roles](https://docs.helixiam.com/integration/workload-identity-roles.md): A workload identity token isn't just proof of *who* a workload is — it carries *what it's allowed to do*. The minted Helix token includes the bound Application client's service-account roles (realm_access.roles / resource_access.roles) and its scopes. - [SDKs — TypeScript](https://docs.helixiam.com/integration/sdk-typescript.md): Add Helix login to any web or Node app, and drive the admin API from code, with one typed package — once it ships. - [SDKs — Mobile](https://docs.helixiam.com/integration/sdk-mobile.md): Ship your own branded authenticator app — device enrolment, push approval, QR login, and transaction signing — backed by the phone's secure hardware. - [Provisioning — SCIM](https://docs.helixiam.com/integration/scim.md): Keep users and groups in sync automatically — in from your HR system or IdP, and out to your downstream apps — over the open SCIM 2.0 standard. - [Provisioning — Webhooks](https://docs.helixiam.com/integration/webhooks.md): Stream realm events to your own systems in real time — HMAC-signed so you can trust every payload. - [Provisioning — Import / export & migration](https://docs.helixiam.com/integration/import-export.md): Move a realm's entire configuration between environments as a single file — export it, commit it, and apply it elsewhere — and migrate in from an existing identity provider. - [Terraform provider](https://docs.helixiam.com/integration/terraform.md): Manage part of HelixIAM as code — version your applications, realm roles, EU Digital Identity Wallet connections and the wallet features built on them in the same workflow as the rest of your infrastructure. - [Account console](https://docs.helixiam.com/integration/account-console.md): Give every user a self-service home for their profile, credentials, sessions, and privacy — no support ticket required. - [Wallet-verified data — Verified data for applications](https://docs.helixiam.com/integration/verified-claims.md): An application can receive what the user's EU Digital Identity Wallet verified in the current sign-in — PID claims, derived age thresholds such as age_over_18, and the claims of other credentials — the standard OIDC way, as OpenID Connect for Identity Assurance verified_claims. - [Wallet-verified data — Verification API](https://docs.helixiam.com/integration/verification-api.md): An application can ask a citizen to prove something with their EU Digital Identity Wallet — "is over 18", "lives in Utrecht", "holds a master's degree" — without a sign-in. - [API reference](https://docs.helixiam.com/integration/api-reference.md): Explore and integrate against the complete admin and protocol API — documented live from the running server. ## Operations - [Operations](https://docs.helixiam.com/operations/index.md): Run HelixIAM in production: keys, branding, access control, privacy, observability and recovery. - [Observability & health](https://docs.helixiam.com/operations/observability.md): Prometheus metrics, health probes, a built-in health dashboard, and SIEM-bound audit forwarding. - [High availability](https://docs.helixiam.com/operations/high-availability.md): Run two or more replicas of helix-iam-server behind a load balancer. Every request may land on any replica: state that a sign-in needs from one request to the next lives in PostgreSQL (or Redis, if you run it), never in one replica's memory. The Helm chart's default is replicaCount: 2. - [Data retention](https://docs.helixiam.com/operations/data-retention.md): A scheduled cleanup deletes rows that have expired, so the database does not keep sign-in data longer than it needs to. It is on by default (added in 1.0.0-rc.13). It runs every 15 minutes in batches of 500 rows with FOR UPDATE SKIP LOCKED, so it is safe with several replicas. - [Hosting municipalities (runbook)](https://docs.helixiam.com/operations/municipality-hosting.md): Run one HelixIAM installation for several Dutch municipalities (gemeenten), one realm each: onboarding, day-2 operations, upgrades and offboarding. - [Backup & disaster recovery](https://docs.helixiam.com/operations/backup.md): One database holds your durable state — back it up well and recovery is straightforward. - [Upgrades & migrations](https://docs.helixiam.com/operations/upgrades.md): Roll forward to a new release with a backward-compatible schema and a zero-downtime deployment order. - [Upgrading to rc.8 / rc.9](https://docs.helixiam.com/operations/upgrade-rc8-rc9.md): What you must change, and what will behave differently, when you move a HelixIAM install from v1.0.0-rc.7 to v1.0.0-rc.8 or v1.0.0-rc.9. - [Upgrading from rc.10 to rc.11](https://docs.helixiam.com/operations/upgrade-rc10-rc11.md): What you must change, and what will behave differently, when you move a HelixIAM install from v1.0.0-rc.10 to v1.0.0-rc.11. - [Upgrading from rc.11 to rc.12](https://docs.helixiam.com/operations/upgrade-rc11-rc12.md): This page lists what you must change, and what behaves differently, when you move a HelixIAM install from v1.0.0-rc.11 to v1.0.0-rc.12. The source is the rc.12 release notes and the security review (findings H4 and H5). - [Upgrading from rc.12 to rc.13](https://docs.helixiam.com/operations/upgrade-rc12-rc13.md): This page lists what you must change, and what behaves differently, when you move a HelixIAM install from v1.0.0-rc.12 to v1.0.0-rc.13. The source is the v1.0.0-rc.13 release notes and upgrade notes. - [Upgrading from rc.13 to 1.1.0-rc.1](https://docs.helixiam.com/operations/upgrade-rc13-1.1.0-rc1.md): This page lists what you must change, and what behaves differently, when you move a HelixIAM install from v1.0.0-rc.13 to v1.1.0-rc.1. The source is the v1.1.0-rc.1 release notes and upgrade notes. - [Upgrading from 1.1.0-rc.1 to 1.1.0-rc.2](https://docs.helixiam.com/operations/upgrade-1.1.0-rc1-rc2.md): This page lists what you must change, and what behaves differently, when you move a HelixIAM install from v1.1.0-rc.1 to v1.1.0-rc.2. The source is the v1.1.0-rc.2 release notes and upgrade notes. - [Upgrading from 1.1.0-rc.12 to 1.1.0-rc.13](https://docs.helixiam.com/operations/upgrade-1.1.0-rc12-rc13.md): Key custody phase 3 (KMIP, plugins, cloud key stores, sovereign key-store policy) and online data-key rotation. - [Upgrading from 1.1.0-rc.13 to 1.1.0-rc.14](https://docs.helixiam.com/operations/upgrade-1.1.0-rc13-rc14.md): This release comes from a self-run of the OpenID Foundation conformance suite against every OpenID Connect OP certification profile (OpenID Connect conformance-suite run). Most of it is new and off until you use it. ## Compliance & security - [Compliance & security](https://docs.helixiam.com/compliance/index.md): How HelixIAM helps you meet security and regulatory obligations — and how to operate it securely. - [OpenID / FAPI conformance](https://docs.helixiam.com/compliance/conformance.md): Certification is an external process run against the OpenID Foundation's conformance suite. This document captures what to run and the readiness state so the certification can be kicked off; the formal mark is awarded by the OpenID Foundation, not by this repository. - [OpenID Connect conformance-suite run](https://docs.helixiam.com/compliance/oidc-conformance.md): HelixIAM was run as an OpenID Provider (OP) against every OpenID Connect OP certification plan of the OpenID Foundation conformance suite, with the suite playing the relying party. - [Compliance program (SOC2 / ISO / eID)](https://docs.helixiam.com/compliance/compliance-program.md): SOC 2 / ISO 27001 and the NL eID accreditations are formal, audited processes owned by people and auditors, not code. This document is the starting map: which Helix capabilities provide the technical controls, and what the organisational process still requires. It does not, by itself, confer any certification. - [Security hardening](https://docs.helixiam.com/operations/security.md): A production checklist to lock down a HelixIAM deployment, plus the high-assurance protocol profiles it supports. - [GDPR & privacy](https://docs.helixiam.com/operations/gdpr.md): Built-in tooling to honour data-subject rights — export, erasure and consent — for both administrators and end users. - [Accessibility (WCAG)](https://docs.helixiam.com/compliance/accessibility.md): HelixIAM's sign-in pages and account console target WCAG 2.1 level A and AA, the level EN 301 549 (clause 9, web content) requires and that Dutch government websites, login pages included, must meet. - [Events & audit](https://docs.helixiam.com/manage/events.md): The events screen is a persisted, searchable audit trail of what happened in a realm — logins, admin changes, and security-relevant actions — with SIEM emission for downstream analysis. ## Reference - [Workload Identity Federation spec](https://docs.helixiam.com/reference/workload-identity-spec.md): Status: proposed · Scope: net-new feature (own epic) · Branch: feature/helix-iam ## Overview - [Licensing](https://docs.helixiam.com/licensing.md): HelixIAM is proprietary software of KubeDNA B.V. Copyright 2026 KubeDNA B.V. All rights reserved.