Why authentik fits healthcare identity work
Self-hosted authentik fits healthcare identity work when you want one identity layer in front of clinical and back-office applications, running inside your own cloud accounts, data centers or segmented networks. Once it is in place, sign-in to EHR-adjacent systems, scheduling, billing, email and remote access can go through one provider that records who signed in, from where and with which factor, rather than through a set of application-local accounts that nobody reviews together. The HIPAA Security Rule (45 CFR Part 164 Subpart C) does not name a product. It applies to covered entities and business associates for electronic protected health information and expects unique user identification, emergency access procedures, automatic logoff and encryption decisions that you can document. authentik supplies the mechanisms (OAuth2/OIDC, SAML and LDAP providers, MFA stages and audit records), but the access rules, the evidence and the decision about whether each addressable specification is reasonable for your organization remain yours to define and record.
Because the platform runs where your data already lives, the architecture questions come first. A deployment has a server container, a worker container and PostgreSQL, which holds all configuration and data except uploaded files, so backup, restore and network placement of that database decide much of your risk profile. Confirm the licensing position with your legal and procurement teams before design starts. Most of the authentik code is under the MIT license (SPDX: MIT), but code in the authentik/enterprise/ directory falls under a separate enterprise license. Several controls healthcare buyers often ask about, such as mTLS client certificate authentication, password history and enhanced audit logging, are listed as Enterprise features on the authentik pricing page, so map each required control to an edition before you assume the open-source build covers it.
A practical first step is to write down which clinical and back-office systems, shared workstations and remote access paths must pass through authentik, and which edition each depends on. That inventory shapes the rest of the project: how you protect access from outside the clinical network, how shared or kiosk workstations handle sessions, and what evidence you can produce for an assessor. Treat the result as input to your HIPAA risk analysis and to the scope you give a partner, not as proof of compliance, because HIPAA has no certification and the Office for Civil Rights judges the outcome of your controls.
Which HIPAA Security Rule requirements shape the identity build
This table maps the HIPAA technical safeguards and business associate terms to the authentik configuration decisions they force. Read each row as a build requirement: what to configure, what evidence to keep, and where teams usually fall short. The main takeaway is that most of the identity work sits in unique user identification, MFA and access paths for remote users, and logging, while the rule itself does not name any product or certification.
| Requirement | What it asks for | What it means for the authentik build |
|---|---|---|
| Unique user identification (164.312(a)(2)(i), required) | Assign a unique name or number to each user and track access to ePHI by that identity. | Use one authentik user per person and disable shared logins. Do not map several clinicians to one account. Confirm that the applications behind authentik record the authentik username, not a generic service account. |
| Emergency access procedure (164.312(a)(2)(ii), required) | Have a documented way to reach ePHI during an emergency when normal access fails. | Plan a break-glass path that does not depend on a single identity flow. Document who can use it, how it is logged and how access is revoked afterward. Test it against an outage of the authentik server or PostgreSQL. |
| Automatic logoff (164.312(a)(2)(iii), addressable) | Terminate electronic sessions after a period of inactivity, or document an equivalent measure. | Set session lifetime and inactivity timeouts in authentik flows and in each relayed application. Shared workstations need shorter timeouts and a fast logout path. Record the chosen values and the reasoning in the risk file. |
| Encryption and decryption (164.312(a)(2)(iv), addressable) | Use encryption to protect ePHI, or document why not and adopt an equivalent measure. | Enforce TLS on every login, SSO and LDAP or RADIUS endpoint. Protect the PostgreSQL database and secret keys that authentik uses. Record whether LDAP is encrypted in transit for each client. |
| Audit controls (164.312(b), standard with no addressable specification) | Record and examine activity in systems that contain or use ePHI. | Forward authentik event logs to your log platform before go-live. Confirm that login, failed login, MFA changes and policy changes are retained. Enhanced audit logging is listed as an Enterprise feature, so confirm what the open-source edition records. |
| Person or entity authentication (164.312(d), standard) | Verify that a person seeking access is the one claimed. | Require MFA for clinical and remote access. Choose second factors that match your risk. Remote access to clinical networks should not rely on a password alone, which is the failure mode in the CNIL finding below. |
| Business associate contract terms (164.314(a)(2)(i)) | Require business associates to meet the Security Rule, flow terms to subcontractors handling ePHI and report security incidents. | If DeployOpen or another partner runs authentik for you, the contract must cover access to the identity system and any ePHI it touches. Ask who holds administrator access, how it is logged and how incidents are reported to you. |
| Sector example: CNIL fine on external access (GDPR Articles 32 and 34) | CNIL fined Hopital Prive de la Loire EUR 500,000 on 3 September 2026 for external access to patient records without VPN or MFA, and access control that ignored the care team's need to know. | For external and contractor access, require a VPN or equivalent path plus MFA. Scope group membership to each care team so role design, not just login, limits what users can reach. |
How clinical, back-office and shared workstation access differ
Clinicians often move between workstations during a shift, so the main design question is how a session starts, follows the person, and ends without leaving clinical data open. In authentik, this usually means planning a dedicated authentication flow for workstation and application sign-in, deciding how quickly a session ends after inactivity, and choosing a second factor that does not slow every handoff. HIPAA treats unique user identification and automatic logoff as distinct technical safeguards, so each needs its own configured answer.
- Login flow: Plan a flow that identifies the individual clinician at each sign-in, so shared hardware never results in a generic or shared account.
- Session lifetime: Decide the inactivity and maximum session settings for clinical applications, then confirm the session and logoff options available in your authentik version.
- Second factor: Choose a factor that a clinician can complete quickly at a shared station, and test how it behaves when the same person signs in several times per shift.
- Logout propagation: Confirm how a logout or session revocation reaches each connected clinical application, not only the identity provider.
- Emergency access: Define a documented break-glass path, separate from routine sign-in, that your policy can audit.
Confirm every session and flow setting against the authentik version you run, because option names and defaults change between releases.
Back-office staff, including those doing EHR administration, scheduling and billing, usually hold broader privileges than individual clinicians but spend more time at their own assigned workstations. Their access design centers on role-based group membership, approvals for elevated rights, and evidence that access ends when a job changes. The HIPAA access control and audit questions focus on who can see which patient records and who can change system configuration, so these roles should map to documented job functions.
- Role groups: Map EHR administration, billing and scheduling to separate groups, and assign applications to groups rather than individuals.
- Privileged access: Decide which administrative actions need a separate, stronger sign-in step, and confirm whether your edition provides privileged access management features.
- Lifecycle changes: Plan how group removal and deactivation happen when someone changes role or leaves, and who verifies it.
- Audit records: Determine which sign-in and administrative events you need to retain, then confirm what the audit logging in your edition records and how you export it.
- MFA coverage: Require a second factor for every back-office account that can reach patient data, including accounts that use LDAP or RADIUS clients.
Check with your EHR vendor which integration method it supports, since that determines which authentik provider type and flow you can use.
External users, such as locum physicians, outsourced billing firms, reference lab staff and vendor support engineers, need access to specific systems without receiving a standing internal account. The design work is about scoping: which applications they reach, how long their accounts last, and how their identity is verified before enrollment. Because these users sit outside your workforce directory, their enrollment and recovery flows and their MFA requirements often differ from those of employees.
- Separate population: Keep external users in their own group or application scope so their policies can differ from workforce policies.
- Enrollment and verification: Plan how an external identity is verified before the account is activated, and who approves that step.
- Time-limited access: Decide how accounts for contractors expire or get reviewed, and confirm which expiry and review features your version provides.
- Recovery: Define account recovery for external users so that it does not rely on a single unverified email address.
- Second factor: Require MFA for every external account and confirm which factor types are available for external users in your edition.
Review your business associate and vendor agreements for each external party, because the HIPAA Security Rule requires business associate contracts to flow the same security terms down to subcontractors that handle ePHI.
Configuration that matters for healthcare deployments
Most healthcare identity work comes down to a handful of authentik settings: which provider each clinical system uses, how MFA is enrolled and recovered, and what evidence the logs can produce. The cards below cover the configuration decisions that shape access control, along with the Enterprise features you need to confirm before you commit to a design.
OIDC and SAML providers for clinical applications
Modern clinical, scheduling and back-office applications usually accept OAuth2/OIDC or SAML, and authentik provides both as provider types. Map each application to one provider, set the redirect URIs and signing settings per application, and restrict assignment with group-based bindings so that only the care team that needs an application receives it. Confirm each vendor's supported protocol and certificate requirements before build, because the EHR or PACS side often dictates the choice.
LDAP provider for legacy clinical systems
Older clinical systems and some medical device management tools authenticate only against LDAP. authentik's LDAP provider lets those systems bind to authentik without a rewrite, but it changes the trust boundary: the LDAP bind path must be reviewed for MFA coverage, password policy and which service accounts can read directory data. Plan the LDAP outpost placement on the clinical network and confirm that each legacy client can use the authentication method you require.
RAC for clinical workstation access
Remote access control lets authentik broker sessions to remote desktops and workstations, which is relevant where clinicians or vendors connect to clinical workstations or servers without direct network exposure. Decide which hosts are reachable through RAC, which accounts can start sessions, and how session start and end are recorded. Confirm the protocols and connection methods your workstation fleet supports before you design the access path.
MFA enrollment and recovery policy
Shared and clinical users are most often locked out during enrollment or recovery, so these flows need explicit design rather than defaults. Define which factors are allowed for clinicians, who can reset an enrollment, how recovery codes or alternate factors are issued, and what happens when a user leaves the care team. Document these rules as part of your access control evidence, and test the recovery path before go-live.
Enhanced audit logging and password history
Enhanced audit logging and password history are listed as Enterprise features on authentik's pricing page, so they are not part of the Open Source edition. Audit logs are the main evidence source for who accessed which system and when, which matters for HIPAA access control reviews. Confirm with authentik which log fields and retention your review needs, and confirm the edition before you rely on either feature in your evidence plan.
mTLS client certificates where Enterprise applies
Mutual TLS client certificate authentication is an Enterprise-only feature on authentik's pricing page. It can support stronger device or service authentication for clinical integrations, but it also brings certificate issuance, rotation and revocation work into your operations. If your design depends on mTLS, confirm the Enterprise edition, the certificate authority you will use, and the revocation process before you commit to the architecture.
Hosting and availability constraints for clinical identity
An identity outage stops clinical work, so the hosting pattern for authentik is a clinical decision, not only an infrastructure one. When sign-in fails, clinicians cannot reach the EHR, medication systems or imaging viewers, and shared workstations may have no fallback. The authentik documentation sets different expectations for each install path. The Docker Compose guide calls for a host with at least 2 CPU cores and 2 GB of RAM and positions Compose for test setups and small-scale production. Confirm with your team whether a single Compose host, with its own backup and restore process, meets the availability your clinical systems require. If it does not, plan for a multi-node Kubernetes install instead.
The Kubernetes guide installs authentik with Helm, but the PostgreSQL bundled with the chart is intended for demonstration and test environments. Production deployments should use a separately managed PostgreSQL service, with its own high availability, backups and point-in-time recovery. Decide early who owns that database, how it is patched, and how failover is tested, because authentik stores all configuration and data in PostgreSQL except uploaded files. Also confirm the database host sits inside the same network zone as the clinical identity path, so a database issue does not become a sign-in issue you cannot diagnose.
Plan for connection growth if you upgrade across the 2025.10 release. That release removed Redis entirely and moved caching, tasks, sessions and WebSocket functions to PostgreSQL, and its release notes warn of roughly 50% more PostgreSQL connections after upgrading. Size max_connections, any connection pooler, and the database instance before the upgrade window, and confirm the figures against the current release notes in your own test environment. Ask your vendor or partner to show a load test that includes peak clinical sign-in periods, such as shift changes, so connection limits are proven before production traffic depends on them.
Compliance evidence DeployOpen can prepare and what it cannot provide
HIPAA does not issue certificates, and the rule itself is being revised. DeployOpen can configure authentik and prepare the records, controls and evidence that a covered entity or business associate reviews, but the audit reports and attestations come from independent assessors and the entity's own compliance program.
Unique user identification records
The Security Rule requires unique user identification as a required technical safeguard. We can set up authentik so each clinician, contractor and service account has its own user record, with no shared logins for clinical applications, and export the user list and group membership as evidence. Check that shared workstation sessions still map to a named individual at sign-in, and confirm how break-glass accounts are recorded.
Access control and offboarding records
Evidence of who could reach ePHI, and when that access ended, is often the weakest part of a review. We can document group-to-application mappings, deactivation steps and the timestamps authentik records when accounts are disabled or sessions are revoked. Confirm with your HR and clinical systems owners how terminations reach authentik, because an account left active in one system is still a path in.
Audit log retention and forwarding
Access reviews and incident investigations depend on logs that survive the server that produced them. We can configure authentik event logging, forward logs to your SIEM or log platform, and document the retention period set on both ends. Confirm the retention period with your compliance lead and test that logs for a sample login, a failed attempt and a deactivation can be retrieved.
Business associate contract terms
Under 45 CFR 164.314(a)(2)(i), a contract with any business associate that handles ePHI must require Security Rule compliance, flow the same terms to subcontractors, and require reporting of security incidents. DeployOpen can supply a description of its controls for your contract review, but the agreement terms are negotiated by your legal team. Check whether DeployOpen will act as a business associate for your engagement before any ePHI is accessible to our staff.
No HIPAA certification exists
HHS states that no Security Rule standard requires certification and that HHS does not recognize private certifications. Any vendor or consultant claiming to certify HIPAA compliance is not offering the thing HHS enforces against. DeployOpen will not issue a HIPAA certificate or attestation. Ask your assessor what evidence they will request, and ask us for a control mapping and configuration records, not a certificate.
Pending Security Rule revision
HHS proposed a major Security Rule revision on 6 January 2025, and as of October 2026 no final rule has been published. The Unified Agenda projects final action for July 2027, so the final text could change the requirements. Track the rulemaking and plan authentik controls, such as MFA and access reviews, so they can be adjusted without re-architecting the deployment.
How a healthcare authentik rollout is phased
The sequence moves from knowing which systems touch ePHI to a tested build, working clinical and back-office sign-in, and remote access that can be evidenced and operated after go-live.
Scope the application inventory and ePHI flows
Your team lists every application that signs users in or stores, displays or transmits electronic protected health information, including EHR modules, imaging viewers, pharmacy and lab interfaces, scheduling, shared workstation apps and vendor portals. For each one, record who uses it, which identity protocol it supports, and where ePHI moves. DeployOpen can run this workshop with your security and clinical informatics leads. The step is done when the inventory is approved, each application has an owner, and the ePHI data flows are mapped against the rollout order.
Build a non-production authentik instance
Install authentik on the method your infrastructure team has chosen, in a test or staging environment inside your network. Docker Compose suits small test setups, while Kubernetes with Helm is the usual path for larger estates, and the chart's bundled PostgreSQL is intended only for demonstration and testing, so production needs a separately managed database. Confirm the version you deploy is one of the supported security lines, 2026.5.x or 2026.8.x, and subscribe to security announcements, since the project publishes security releases at least 24 hours in advance. The step is done when the instance runs from your configuration, backups restore in test, and the patch process is written down.
Integrate priority clinical and back-office apps
Configure providers for the first wave of applications, starting with the systems that carry the most ePHI or the most users. Use OAuth2/OIDC or SAML where the application supports them, and plan LDAP or proxy patterns for legacy systems that do not. Map groups to roles based on the need-to-know model your compliance team has approved, not on directory convenience. The step is done when each priority application signs in through authentik in test, role mapping matches the approved matrix, and a named business owner has tested access.
Test MFA and shared workstation behavior
Enforce multi-factor authentication for clinical and remote access in test, then walk through the workflows that matter on clinic floors: fast user switching, session timeouts on shared machines, badge-based or kiosk logins where they are in use, and recovery when a second factor is lost. Confirm each user is uniquely identified and that automatic logoff and session limits behave as your policy requires. Test under realistic clinical conditions with clinicians, not only administrators. The step is done when the test log shows each workflow passed, exceptions are documented with approvals, and the help desk has a tested recovery procedure.
Cut over remote access to clinical networks
Move remote access for staff, contractors and vendors onto authentik-backed authentication, sequenced by group so you can roll back one population at a time. Coordinate with the team that runs your VPN or access gateway, and confirm that external users reach only the systems their roles allow. Keep the previous access path available until the cutover is verified. The step is done when remote sessions authenticate through authentik with MFA, the rollback path has been exercised, and the access change is recorded in your change system.
Capture access control evidence
Collect the records an assessor or regulator would ask for: the approved access matrix, configuration exports, MFA enforcement settings, audit log samples, test results and the cutover change record. Map each item to the HIPAA technical safeguard it supports, such as unique user identification, automatic logoff and access control, and note which implementation specifications your organization treats as addressable and why. DeployOpen prepares the evidence, but auditors and HHS do not certify compliance through a vendor. The step is done when an evidence folder exists for each control, owners have reviewed it, and gaps have tickets.
Hand over operations and plan upgrades
Move the running system into operations with monitoring, log forwarding, backup schedules and a documented on-call path. Agree who reviews security announcements, who tests each upgrade in staging, and how the sequence of upgrades is planned around your release cadence. Note that authentik releases are named by year and month, and that the 2025.10 release removed Redis in favor of PostgreSQL, which changes connection planning. The step is done when runbooks are signed off, the upgrade calendar is owned by a named person, and the first patch cycle has been rehearsed.
What healthcare teams ask before hiring a partner
What drives the cost of an authentik deployment for a healthcare organization?
The main drivers are scope, the number of applications to integrate, the user populations involved and the hosting model. A deployment that covers one clinical application for staff is very different from one that covers EHR access, back-office systems, shared workstations and remote access for external clinicians. Each protocol and each application adds configuration, testing and sign-off work. Costs fall into two groups: one-time work (design, build, integration, testing, cutover) and recurring work (upgrades, monitoring, backups and support). Your own infrastructure costs, such as servers, PostgreSQL and storage, are separate from partner fees. Ask any partner for a quote that lists these items separately, tied to a written scope.
Do we need an authentik Enterprise license for healthcare use?
Not for every deployment. Most of the code in the authentik repository is under the MIT license, and the Open Source edition is free. The authentik pricing page lists Enterprise at $5 per user per month billed annually, plus $0.02 per external user per month, and Enterprise Plus starting at $20k annually. Enterprise adds features such as mTLS client certificate authentication, privileged access management, password history and enhanced audit logging, which some healthcare teams evaluate for access evidence. Code in the authentik/enterprise/ directory falls under a separate license, so confirm the terms with your counsel before you mix editions. Check current pricing directly on the pricing page, since figures can change.
How long does an authentik healthcare deployment take?
Timeline depends on the number of applications, the protocols each one requires, how many identity sources must be connected, and how long testing and clinical sign-off take. Applications that already support OIDC or SAML are usually quicker than legacy systems that need LDAP, a proxy outpost or custom configuration. Change windows, validation of access rules against clinical roles and cutover planning also add time. A fixed-scope engagement sets the timeline in writing before work starts, so ask for the milestones, the testing steps and the dependencies on your side. We do not give a generic duration without a defined scope.
What must our team provide for an authentik engagement?
Healthcare engagements depend on inputs from several groups:
- Application owners who confirm login methods, roles and the data each system exposes
- Identity data and HR or directory sources, with rules for joiners, movers and leavers
- Change windows approved by operations and clinical leaders for cutover and rollback
- Clinical sign-off on access rules, including which care teams need which records
- Security and compliance contacts who review access control design and evidence
- Infrastructure access to the environment where authentik will run
Missing inputs are the most common cause of delay, so agree on named owners and dates before the scope is signed.
Can our internal team deploy and run authentik without a partner?
Yes, if you have engineers who can run containers or Kubernetes, manage PostgreSQL, configure identity protocols and test access changes carefully. The Docker Compose guide positions that method for test setups and small-scale production, while the Kubernetes guide recommends a separately managed PostgreSQL for production. Healthcare environments add requirements for documented access decisions, change control and evidence, which take extra time to build. Many teams split the work: an internal team owns daily operations while a partner handles design, integration, hardening or an upgrade. Assess your staffing honestly against the work described in the scope.
Does HIPAA certification exist for authentik or our organization?
No. HHS states that no Security Rule standard requires an entity to certify compliance, and that HHS does not endorse or recognize private certifications. Private certifications also do not prevent HHS from later finding a violation. The HHS Office for Civil Rights enforces the Security Rule through complaints, compliance reviews and audits. Be cautious about any vendor or partner that claims HIPAA certification. DeployOpen prepares systems, controls and evidence for compliance assessments but does not issue audit reports, attestations or certifications. Independent assessors and HHS handle those questions.
What support is available after an authentik go-live?
After go-live, the work shifts to operations: monitoring, backups, log review, upgrades, access reviews and fixing lockouts or sync problems. Most engagements are fixed-scope, and ongoing support, upgrades and continuous testing are available as retainers. Before you sign, ask what is covered, how incidents are escalated and who can approve changes during clinical hours. Plan for authentik upgrades, which should follow the sequential upgrade rule and the supported versions in the security policy, with security releases announced at least 24 hours in advance. Confirm the support levels you need with the partner in writing.
What to ask a partner before signing a healthcare scope
Start with ePHI, because it decides what the partner is allowed to touch. Ask whether test and staging environments will contain real patient data, and if not, how realistic test records will be generated and where any copies of production data will live, who can reach them and how they are deleted. Ask whether the partner will sign a business associate agreement before any engagement that touches electronic protected health information. Under 45 CFR 164.314(a)(2)(i), that contract must require the partner to comply with the Security Rule, flow the same terms down to any subcontractor that handles ePHI, and report security incidents to you. Confirm the partner's position on subcontractors, its incident notification window and where its engineers will work from, and have counsel review the agreement rather than relying on a template from either side.
Next, ask how the fixed-scope written agreement defines the work. The scope should name each authentik component in the build, such as the server and worker containers, the PostgreSQL database and each provider type, along with the clinical and back-office applications, user populations and sites in scope. It should also list the test evidence each deliverable produces. Ask how emergency access and shared workstation cases will be tested: whether there is a documented break-glass path that is exercised and logged, how automatic logoff behaves on shared clinical devices, and whether the partner will test handoff between shifts and locked-out accounts. Ask who signs off on acceptance and what happens to open defects after go-live.
Finally, clarify what happens after the build. Ask whether ongoing support, upgrades and continuous testing are covered by a retainer, and what the retainer excludes. Authentik publishes its own release cadence and security policy, so ask how the partner will track supported versions, schedule upgrades in your change windows and handle security releases announced with short notice. Ask who is responsible for PostgreSQL maintenance and backups, and whether restore tests are included. Remember that DeployOpen prepares evidence for assessments but does not issue audit reports or certifications, and HIPAA has no certification, so ask the partner to show the evidence it will hand over and which parts your own compliance team must still assess.
How DeployOpen scopes and delivers healthcare authentik work
DeployOpen plans, implements, hardens, documents and supports self-hosted open-source platforms inside your own infrastructure, including authentik for healthcare. Engagements are fixed-scope, with scope, deliverables and timelines agreed in writing before work starts.
How we scope
- Inventory clinical, back-office and remote access applications that need SSO, and record which protocol each one supports.
- Map shared workstation, badge and kiosk login needs against the user populations that actually use them.
- Agree in writing which HIPAA technical safeguards, access reviews and audit evidence the authentik work will support.
How we build
- Deploy authentik in your own cloud accounts or data centers, with PostgreSQL managed separately from the chart or Compose test setup.
- Configure providers, MFA stages and session timeouts for each application, and test unique user identification and emergency access paths.
- Run functional and security tests on sign-in, lockout, logoff and remote access paths before any clinical user is switched over.
How we hand over
- Document the configuration, role mappings, break-glass procedure and the evidence each control produces for your compliance team.
- Train your administrators on daily operations, backup and restore steps, and how to review access logs.
- Confirm with your auditors or compliance advisers which controls and evidence formats they expect before final acceptance.
How we support
- Offer ongoing support, version upgrades and continuous testing as a retainer, scoped separately from the original build.
- Plan authentik upgrades around the sequential upgrade path and the release notes for each version you run.
- Review access configuration and test remote access paths on a schedule agreed with your security and clinical leads.
