Keycloak for healthcare: HIPAA access control

Why Keycloak for healthcare sign-in, and what changes for your team

If you lead health IT, you probably run many clinical and administrative applications, each with its own login, and you serve staff, contractors and outside users who need different levels of access. Keycloak can centralize sign-in for these applications on infrastructure your organization controls. The design, however, should not start from the software. It should start from the HIPAA Security Rule duties for access control and audit, and from what clinicians and care teams actually need to reach, when and from where.

Keycloak supports OpenID Connect, OAuth 2.0 and SAML 2.0, so it can front modern web and API applications as well as older clinical systems that only speak SAML. It also provides single sign-on, identity brokering to upstream directories and providers, user federation, and an admin console. Those capabilities help with unique user identification and access management, but they do not make your organization compliant on their own. Under 45 CFR 164.302, covered entities and business associates remain responsible for the Security Rule for all electronic protected health information they handle, and that responsibility does not move to the identity platform or to the partner who deploys it.

For your team, the practical change is that access decisions move from individual applications into a shared identity layer. Application owners will need to register clients, agree on token lifetimes and claims, and map roles to clinical functions. Your identity administrators will own realms, user federation and group or role structures, and they will need a documented process for granting, changing and removing access. Start by listing the applications that hold ePHI, the user populations for each, and the existing directory they draw from. That inventory will show where a single sign-in flow is feasible and where an application needs its own exception.

Several Security Rule specifications will shape the configuration. Unique user identification is a required implementation specification, so shared logins for clinical workstations need a documented exception or a different approach. Automatic logoff is addressable, which means you must assess whether session timeouts are reasonable and appropriate for shared clinical terminals, and document the reason if you choose a different equivalent measure. Audit controls and the review of login activity will depend on what Keycloak records and where those logs are sent. Confirm in your environment which events your Keycloak version persists and how long your retention policy requires them to be kept.

Which HIPAA and healthcare requirements shape the Keycloak build

This table maps the HIPAA, NIS2 and GDPR requirements that most affect a Keycloak healthcare build to the configuration decisions they create. Read each row as the requirement, what it asks for, and what it means for your identity design. The main takeaway is that Keycloak supplies identity controls, while contracts, documented assessments and risk decisions remain your organization's responsibility.

Requirement and source	What it asks for	What it means for the build
Unique user identification and emergency access (45 CFR 164.312, required)	Each user has a unique identifier, and a documented procedure must allow access during an emergency.	Give every clinician and administrator an individual account, and define a governed emergency account with logged use.
Automatic logoff and encryption (164.312, addressable, assessed under 164.306(d))	Terminate idle sessions and protect ePHI in transit and at rest, or document why and what equivalent measure applies.	Set session timeouts in the realm, enforce TLS on all communication, and record the addressable assessment for each specification.
Business associate contracts and incident reporting (45 CFR 164.314)	Business associates must comply with the Security Rule, flow terms to subcontractors and report security incidents.	Name who operates the identity service in the contract, and keep login and admin event logs that support reporting timelines.
No HIPAA certification (HHS FAQ 2003)	No Security Rule standard requires certification, and HHS does not recognize private certifications.	Ask partners for control evidence and assessment results, not a HIPAA certificate. OCR reviews compliance through complaints, reviews and audits.
NIS2 health sector listing (Directive (EU) 2022/2555, Annex I)	Health is listed as a sector of high criticality, including healthcare providers and certain medical device manufacturers.	If your EU operations fall in scope, document identity controls as security measures. Confirm applicability with counsel.
GDPR and CNIL access control finding (GDPR Articles 32 and 34)	France's CNIL penalized a hospital in 2026 for external access without MFA and access that ignored the care team's need to know.	Illustrative example: enforce MFA for external access and map roles to actual care relationships. Test these rules, not only the login page.

How Keycloak settings map to the HIPAA technical safeguards

The technical safeguards in 45 CFR 164.312 cover access control, audit controls, integrity, person or entity authentication and transmission security. For a team running Keycloak as the sign-in service for clinical and workforce applications, most of the identity-related obligations land on a small set of realm settings. This section explains which settings support which standard, what each one does not cover, and what to confirm against your own risk analysis before you treat any of them as part of your safeguard design.

Unique user identification under 164.312(a)(2)(i) is a required implementation specification. In Keycloak, this means every workforce member and integrated clinical application user resolves to a single user record, with no shared accounts used for clinical sign-in. Keep local users, LDAP or Active Directory federation and identity brokering mapped to one identity per person, and review any service or shared accounts in the realm separately. Confirm with your security officer how shared kiosk or badge-based workflows are handled, because Keycloak will only enforce uniqueness for the identities you have created. Emergency access under 164.312(a)(2)(ii) is also required, and Keycloak does not supply that procedure; it has to be documented and tested outside the realm.

Automatic logoff under 164.312(a)(2)(iii) is addressable, which means you must decide whether it is reasonable and appropriate for your environment and document the outcome. Keycloak's session settings, including SSO session idle and maximum lifespans and client-level session overrides, are the technical levers. Shorter values suit shared workstations in clinical areas, while longer values may be justified for a single-clinician device with screen locking at the operating system. Set these per client where possible, test them with the applications that actually sign in, and record the reasoning. Encryption and decryption under 164.312(a)(2)(iv) is addressable and sits largely outside Keycloak's realm settings, though the production guidance expects TLS on all communication.

Multi-factor authentication matters for person or entity authentication under 164.312(d), which is a standard rather than an implementation specification. Keycloak's OTP policies support time-based one-time passwords, while WebAuthn and passkeys offer phishing-resistant options that you can require for privileged or remote access flows through authentication flow configuration. Recovery codes need a deliberate policy: they restore access when a device is lost, but each code is a credential, so decide how they are issued, stored and retired. Confirm with the business owner who can reset factors and how that action is verified, since a weak reset process undermines the MFA setting.

Audit controls under 164.312(b) require mechanisms that record and examine activity in systems containing ePHI. Keycloak's event logging and the login failure records persisted to the database by default in the 26.8 line give you raw material for those reviews, and metrics exposed on the management interface can support monitoring. Keycloak does not decide what your audit program reviews, how long records are retained, or who looks at them. Those are decisions for your risk analysis and your business associate agreements. Keycloak helps with these technical controls, but it does not make an organization compliant with the Security Rule, and HHS does not issue certifications. Confirm each setting described here against your own risk analysis, document the rationale for any addressable choice under 164.306(d), and have counsel or your compliance lead review the final configuration.

Modules, settings and integrations that matter in healthcare

A healthcare Keycloak deployment usually combines a few areas: how staff and external users sign in, how multi-factor authentication is enforced, how clinical applications register as clients, and how administration and monitoring are kept separate from public traffic. The cards below cover the settings that most affect access control and audit evidence, and what to confirm before a design is locked.

Workforce sign-in through directory federation

Staff identities usually live in an existing LDAP or Active Directory domain, so Keycloak's user federation connects to that directory rather than copying accounts. Kerberos support lets domain-joined workstations sign in without a second password prompt. Before go-live, confirm which attributes sync, how disabled accounts and leavers are handled, and whether group membership maps to clinical roles.

Patient and partner sign-in through brokering

Patients, referring clinics and contracted partners often hold identities outside the hospital directory, so Keycloak can broker them to external OIDC, OAuth or SAML providers, or to social providers where policy allows. The Organizations feature groups partner clinics and their email domains, which lets each partner manage its own members within limits you set. Confirm which external identity providers are approved and how their logins are logged.

MFA policies for clinical access

Keycloak supports OTP, WebAuthn security keys, passkeys and recovery codes, and the authentication flow determines which of these a user must complete. Remote access to patient records is the case regulators examine most closely, so enforce a second factor for external and VPN-less access at minimum. Decide who issues recovery codes, how lost hardware keys are replaced, and how shared workstations affect passkey use.

Clinical app clients over OIDC and SAML

Each clinical application needs its own client with defined redirect URIs, scopes and token lifetimes. On Kubernetes, the Keycloak Operator's KeycloakOIDCClient and KeycloakSAMLClient resources let you declare these clients as code and review changes through version control. Check that secrets are not stored in plain manifests, that each client receives only the roles it needs, and that retired applications are removed.

Admin console on a separate hostname

Keycloak's production guidance is to serve the admin console and Administration REST API on a different hostname or context path from public frontend URLs. A reverse proxy with path restrictions can then block administrative routes from the internet while staff reach them over an internal network. Confirm the proxy rules, the network path for administrators, and which accounts can reach the admin endpoints at all.

Metrics for monitoring access events

Starting Keycloak with --metrics-enabled=true exposes Prometheus-format metrics at /metrics on the management interface, which supports alerting on login failures and unusual authentication volume. Metrics show activity patterns but are not a full audit trail, so pair them with event logging for individual access records. Confirm that the metrics endpoint is reachable only by your monitoring system, and that retention meets your record-keeping policy.

Connecting EHR and clinical applications over OIDC and SAML

The first decision for each clinical application is which protocol its vendor actually supports and how far that support reaches. Keycloak supports OpenID Connect, OAuth 2.0 and SAML 2.0, so an EHR, patient portal or imaging viewer can usually be registered as a client in one of those protocols, but the application vendor's documentation decides the final choice. Some clinical products accept only SAML, some require OIDC with specific scopes, and some need a launch flow that Keycloak does not orchestrate by itself. Before any client is created in a realm, ask each vendor in writing which protocol, which grant types, which token claims and which logout behavior they certify, and record the answer next to the client definition. Do not assume that a product listed as "OIDC compatible" accepts every Keycloak default. Redirect URIs deserve the same care as the protocol choice. Each OIDC client should list exact redirect URIs for every environment, including test and training instances, and avoid wildcards that let an attacker register a look-alike callback path. For SAML, confirm the assertion consumer service URL, the entity ID format and the signing and encryption certificates, and plan a dated rotation for each. Token lifetimes should be set per client rather than inherited from the realm default. A shorter access token lifetime and a session idle timeout suited to shared workstations in wards or clinics reduce exposure, but a lifetime that is too short can force repeated sign-ins during a clinical task. Test the chosen values with the vendor's refresh behavior, because some applications handle refresh tokens poorly. Role mapping is where clinical access control becomes specific. A nurse, a radiologist, a billing clerk and a patient do not need the same records, and the HHS Security Rule's access and unique user identification expectations apply to every route into ePHI. The Hopital Prive de la Loire case, fined by the CNIL in September 2026 under GDPR Articles 32 and 34, cited access control that ignored the care team's need to know. Design realm roles and client roles around the job functions the application enforces, then map Keycloak groups or identity provider attributes to those roles. Keep the mapping in version control, because each change to who may open which chart is a change to an access decision. Ask each vendor which claim carries role or department information, how it handles missing claims, and whether it defaults to read access when a claim is absent. Before go-live, verify every integration against a written test list rather than a single successful sign-in. Check that an unauthorized role is refused, that logout from one application ends the session in the others as the vendor specifies, that backchannel logout tokens are validated where the application supports them, and that an expired token produces a clean re-authentication. Confirm that audit records in the application and in Keycloak can be correlated by user and time. Keep the redirect URI list, certificate inventory and claim mapping as evidence for the assessor. DeployOpen can plan and build these integrations in infrastructure you control, but the vendor's written support statement for your EHR version is the document to obtain first. Confirm the supported protocol, the claim format and the logout behavior for each product before the build plan is signed off.

How a healthcare Keycloak rollout runs

The sequence moves from agreed risk and scope to a tested, audited sign-in service that clinical staff use and your team can operate. Each phase closes with a written output that the security officer and application owners can review before the next phase starts.

Agree risk, scope and ePHI boundaries
DeployOpen works with your security officer to map which systems hold electronic protected health information, which user groups need access and which applications join the first release. The team records the HIPAA Security Rule standards that apply, the addressable specifications you decide to implement and any business associate terms that cover the hosting or support partner. The step closes with a signed scope document and a risk register that names the owner of each open decision.
Design the environment and high availability
The team selects the hosting model, database engine and high availability architecture that fit your data center or cloud accounts, then documents the network path. The design covers TLS on all communication, a reverse proxy with path restrictions, and a separate hostname or context path for the admin console and Administration REST API. It also confirms the synchronously replicated database that supported multi-site designs require. The step closes with an architecture diagram, a sizing note and an installation method (Operator, kubectl or another approved option) that your platform team has reviewed.
Build realms, clients and federation
The team creates realms that separate workforce and patient sign-in, then connects directory sources such as LDAP or Active Directory and any external identity providers your organization uses. It sets OTP or passkey policies, configures recovery codes, and defines role and group mappings that enforce unique user identification for every account. Emergency access accounts are created under a documented procedure with their own monitoring. The step closes with an exported configuration in version control and a test report showing each realm, provider and policy behaving as the design states.
Pilot the clinical application with a limited group
DeployOpen connects one clinical application over OIDC or SAML and runs it with a small group of clinicians, nurses or administrators chosen by the application owner. The pilot checks sign-in, session timeouts, role claims, logout behavior and the fallback path when the identity service is unavailable. Users report issues through a defined channel, and each change goes through the same review as the production configuration. The step closes when the application owner accepts the pilot results in writing and the open defects are either fixed or accepted with a documented risk.
Validate audit logging and monitoring
The team confirms that authentication events, administrative changes and failed logins are recorded, and that the records reach the logging platform your security team reviews. It enables the metrics endpoint on the management interface, sets alerts for abnormal sign-in patterns and checks that log retention matches your policy. Login failures are stored in the database by default in the current release, so the team confirms how long those records are kept. The step closes with a logging test report that maps each control to the evidence your auditors or the HHS Office for Civil Rights may request.
Train staff and cut over production
DeployOpen prepares short guides for administrators, help desk staff and end users, covering enrollment, password and passkey recovery, and the steps for reporting a suspected compromise. Training sessions run before cutover, and the help desk rehearses the emergency access procedure. The cutover plan sets the sequence of application switches, the rollback point and the owner who approves each switch. The step closes when every application is live on the production realms, the rollback plan has been rehearsed, and the operations team has signed the handover.
Operate and plan upgrades under approval
After cutover, the operations team runs monitoring, backups and access reviews against the agreed runbook. Upgrades are planned as a separate change: the team reads the release notes for each version, tests the new release in a non-production copy, and reviews any database migration method with your database administrators. Operator updates use manual approval mode, so no upgrade starts without a named approver. The step closes with a quarterly review record covering patches applied, access changes and any upgrade decisions approved by your owner.

Keeping Keycloak current without breaking clinical access

Upgrading to the Keycloak 26.8 line changes four behaviors that can stop clinicians from signing in, so the 26.8 upgrade notes should be checked against your own realm configuration before any upgrade window is scheduled. The current release is 26.8.1, published October 13, 2026. For a hospital or clinic, the four items with the most direct effect on clinical access are enforced SMTP StartTLS, mandatory signature validation of backchannel logout tokens, login failures persisted to the database by default, and the recommended move from the deprecated multi-site feature to the stateless feature. Each one needs an owner and a test before the change reaches production.

Enforced StartTLS means the mail relay behind password reset, email one-time codes and account notices must offer STARTTLS, and Keycloak will not fall back to plaintext. If your hospital relay or a third-party mail service supports it only optionally, reset emails will stop and locked-out staff will have no self-service recovery. Ask the mail team to confirm the relay's TLS behavior and send a test message from a staging realm. Backchannel logout is the second check. From 26.8, Keycloak validates the signatures on logout tokens from external providers. Confirm that every brokered partner and clinical application that sends logout tokens has its signing keys registered, or session termination for departing staff may fail silently.

Login failures are now written to the database by default. This strengthens the record of failed access attempts that a HIPAA audit controls review would examine, and it supports investigation of credential attacks against clinician accounts. The cost is more database writes and a table that grows over time, so set a retention period, confirm the database has capacity for it, and check that failed-login events reach the same log pipeline your security team reviews. The upgrade notes also recommend moving from the deprecated multi-site feature to the stateless feature. If your design uses the older per-site Infinispan model, treat that move as an architecture change with its own test cycle, not as a settings update made during a routine patch.

Schema migration runs automatically at startup by default. That is convenient for a small test or departmental realm, but for a large production database the upgrading guide suggests manual migration, where your database administrator applies the SQL and reviews it before the new server version starts. Choose the method per environment, document the decision, and rehearse the full upgrade on a recent copy of production data. Since Keycloak 26.0, the project plans four minor releases a year and a major release every two to three years, and it says breaking changes in a minor release will be opt-in. That cadence means upgrades are a recurring operational task. Build a calendar with staging soak time, and if you run the Keycloak Operator, follow its recommendation to use manual approval mode so that no update reaches a clinical realm without review.

Compliance considerations for a healthcare Keycloak deployment

The HIPAA Security Rule and the obligations around it decide what a Keycloak deployment must restrict, record and prove. The cards below cover who is in scope, how assurance works, how enforcement and penalties apply, where the rules are still changing, and which EU obligations apply to EU patient data.

Who the Security Rule covers

The Security Rule in 45 CFR Part 164 Subpart C applies to covered entities, which are health plans, health care clearinghouses and covered health care providers, and to their business associates. It covers all electronic protected health information they create, receive, maintain or transmit. For Keycloak, confirm whether the sign-in service stores, passes or can reach ePHI, and whether any vendor operating it is a business associate under a contract that flows the same terms to subcontractors.

No certification, so evidence matters

HHS states that no Security Rule standard requires certification and that private certifications do not prevent HHS from later finding a violation. Auditors and the HHS Office for Civil Rights review your documented configuration, access decisions and logs. HITRUST is an optional third-party assessment with its own control set and rules, and its e1 and i1 certifications last one year while r2 certifications last two. DeployOpen prepares evidence and does not issue attestations or certifications.

OCR enforcement and penalty exposure

The HHS Office for Civil Rights enforces the Security Rule through complaint investigations, compliance reviews and audits. Its 2024 to 2025 HIPAA audits review 50 covered entities and business associates on provisions most relevant to hacking and ransomware. For penalties assessed on or after January 28, 2026, 45 CFR 102.3 sets civil money penalties from $145 to $2,190,294 per violation, with a calendar-year cap of $2,190,294. Confirm that sign-in events, failed logins and admin changes can be produced on request.

Proposed Security Rule revision pending

HHS proposed a major Security Rule revision on January 6, 2025 (90 FR 898, RIN 0945-AA22), with comments due March 7, 2025. As of October 2026 no final rule has been published, and the latest Unified Agenda projects final action for July 2027. Design the Keycloak controls against the rule in force today, and check the rulemaking status on the Federal Register and reginfo.gov before the design is approved, since final requirements may differ from the proposal.

NIST SP 800-66 Rev. 2 as the guide

NIST SP 800-66 Rev. 2, published in February 2024, is a resource guide for implementing the Security Rule. It gives key activities, descriptions and sample questions for every standard. HHS lists it as informational and not legally binding. Use it to map each standard to a Keycloak setting, such as unique user identification, automatic logoff and audit controls, and record which setting answers which question.

GDPR and EHDS for EU patient data

Where EU patient data is involved, GDPR (Regulation (EU) 2016/679) sets security and breach obligations that the HIPAA analysis does not replace. In September 2026, France's CNIL fined the Hopital Prive de la Loire EUR 500,000 under GDPR Articles 32 and 34, citing external access to its patient record system without VPN or multi-factor authentication. Check also Regulation (EU) 2025/327 on the European Health Data Space and NIS2, which lists health as a sector of high criticality.

Questions healthcare teams ask before they scope a Keycloak project

What drives the cost and effort of a Keycloak project?

The main drivers are the number of applications that need sign-in, the number and type of identity sources, the high availability design, and how much validation and documentation the project must produce. Applications multiply the work because each needs its client configuration, claim mapping, test cases and owner sign-off. Federation sources such as LDAP, Active Directory or external identity providers add mapping, attribute rules and failure testing. High availability adds database, cluster and failover design. Validation and documentation scale with the evidence your compliance and audit teams need. Ask any partner to break the quote down by these drivers, so you can see which items would shrink if you narrow the scope.

Which Keycloak costs are one-time and which recur?

Design, build, integration, testing and documentation are one-time costs tied to the written scope. Recurring costs come from keeping the platform current: applying minor and major releases, patching the operating system, database and container images, reviewing release notes for changed defaults, and monitoring. Keycloak plans four minor releases a year, so the upkeep load is continuous rather than occasional. If you want a partner to handle that work, it is usually sold as a support or maintenance retainer. Ask for the one-time and recurring items to be listed separately in the quote, with what each one covers and how changes to scope are handled.

How long does a Keycloak healthcare project take?

Duration depends on the scope, so no general timeline applies. The main variables are how many applications are onboarded, how many identity sources must be connected, whether high availability is required from day one, and how quickly your application owners and identity team can review and test. Most engagements are fixed-scope, and the schedule, deliverables and milestones are agreed in a written plan before work starts. Ask for the plan to name the dependencies on your side, such as access to the environment, test accounts and sign-off dates, because those are the most common causes of delay.

What must our team provide before a Keycloak project starts?

You need to provide the identity sources and their attribute details, the owners of each application that will use sign-in with their protocol and redirect requirements, a risk analysis or the inputs for one, and test users covering each role and care-team scenario. You also need access to the target infrastructure, a decision on hosting and database, and a named contact who can approve design choices. Missing identity source details and unavailable application owners are the usual reasons projects slow down, so confirm these responsibilities in the written scope before signing.

Can our internal team deploy Keycloak healthcare sign-in without a partner?

Yes, many internal teams deploy Keycloak themselves, since it is open source under the Apache 2.0 license and has extensive documentation. The question is capacity and evidence. A production setup needs TLS everywhere, a reverse proxy with path restrictions, a separate admin hostname, a supported production database, a high availability design, metrics, backups, and an upgrade process. Healthcare teams also need the access control and audit configuration documented and tested against their own risk analysis. Assess whether your team has the skills, time and on-call coverage for that work, and whether it can keep pace with the release cadence over the life of the system.

Does using Keycloak make our organization HIPAA compliant?

No. HIPAA has no certification, and Keycloak is software, not a compliance status. The HIPAA Security Rule applies to covered entities and business associates for the electronic protected health information they handle, and compliance depends on their overall safeguards, policies and operations. Keycloak can support technical safeguards such as unique user identification, automatic logoff, encryption in transit and audit logging, but those settings must be configured, documented and assessed in your environment. Independent auditors and certification bodies issue any attestation or report, and DeployOpen prepares systems, controls and evidence for those assessments rather than issuing them.

What should a quote for a Keycloak project include?

A useful quote follows from a written scope and lists the applications and integrations in scope, the identity sources, the high availability design, the database and hosting assumptions, the validation and documentation deliverables, and the client responsibilities. It should separate one-time build work from recurring support, upgrades and patching, and state what is excluded. Ask how change requests are priced, what acceptance criteria close each deliverable, and what happens if a client dependency is late. DeployOpen does not publish a price list, so a quote is always produced from the agreed scope.

How DeployOpen scopes and delivers healthcare Keycloak work

DeployOpen plans, implements, hardens, documents and supports self-hosted Keycloak inside your own cloud accounts, data centers or air-gapped networks. For healthcare, the work starts with a written scope that separates workforce sign-in, patient-facing sign-in and clinical application integrations, so each one is designed and tested on its own terms.

How we scope

We confirm which user populations sign in, such as clinicians, staff, patients and external partners, and which realms or organizations each one uses.
We map every clinical application to its OIDC or SAML integration method and record which claims, roles and session settings each one needs.
The written scope lists the HIPAA-related access control and audit settings in Keycloak we will configure, and the items your compliance team owns instead.

How we build

We deploy Keycloak on the database, high availability design and TLS configuration agreed in scope, with the admin console on a separate hostname from public sign-in URLs.
We configure MFA, OTP policies, WebAuthn or passkeys, and session and logout behavior, then test each setting against the user populations defined in scope.
We integrate each clinical application, test sign-in, token refresh and logout end to end, and enable metrics and audit logging for operations teams to review.

How we hand over

We deliver configuration documentation, runbooks for account lifecycle and incident response, and a record of the test results against the agreed scope.
We walk your administrators through realm administration, client registration and upgrade procedures, so your team can operate the platform after handover.
We agree which evidence your auditors will request, such as configuration exports and access review records, and confirm it is retained in your environment.

How we support

Engagements are fixed-scope, with scope, deliverables and timelines agreed in writing before work starts.
Ongoing support, Keycloak version upgrades and continuous security testing are available as a retainer, and the retainer scope is agreed in writing.
Before each Keycloak upgrade, we review the release notes for changes that affect healthcare sign-in, then test in a staging environment you control.

Keycloak for healthcare