How authentik supports HIPAA access controls for ePHI systems
authentik can support the access control safeguards in 45 CFR 164.312 for systems that hold ePHI, but only the identity-layer part of them. The Security Rule requires covered entities and business associates to have technical policies and procedures so that only persons or software programs granted access rights can reach ePHI. A self-hosted authentik deployment can provide unique user identification, access policy enforcement, session termination after inactivity and multi-factor authentication for the systems you place behind it. It does not perform your risk analysis, write your policies, train your workforce, encrypt ePHI at rest or decide who should have access in the first place. Those decisions remain yours, and the Security Rule treats them as separate obligations.
authentik's open-source edition is licensed under MIT for most of the code, according to the project's LICENSE file. Code in the authentik/enterprise/ directory falls under a separate enterprise license. The pricing page places Google Workspace and Microsoft Entra ID integrations, mTLS client certificate authentication, password history and enhanced audit logging in the Enterprise tier, so confirm with the vendor which features your HIPAA design depends on before you select an edition. HIPAA has no certification. HHS states that no Security Rule standard requires certifying compliance and that private certifications do not prevent a later finding of violation. DeployOpen configures authentik, prepares the controls and assembles the evidence described on this page, but it does not issue audit reports, attestations or certifications. An independent assessment, your own risk analysis and your privacy officer's review remain necessary.
Which HIPAA technical safeguards map to which authentik configuration
This table pairs each HIPAA technical safeguard that touches sign-in with the authentik configuration that supports it, the implementation specification status from Appendix A to Subpart C, and the evidence to keep. Read the status column first, since required items need a working control and addressable items need a documented decision. The main takeaway is that authentik covers identity, access and authentication, but the emergency access procedure remains a process you must design yourself.
| Requirement | Specification status | authentik configuration | Evidence to keep |
|---|---|---|---|
| Access control standard, 164.312(a)(1) | Standard: only granted users and programs may access ePHI | Applications bound to providers, with group membership and policy bindings deciding who can sign in | Exported application and policy bindings, group membership history, access approval records |
| Unique user identification, 164.312(a)(2)(i) | Required | One account per person for each ePHI application, with no shared or generic sign-in accounts | User directory export, naming rules, records showing shared accounts were prohibited or removed |
| Automatic logoff, 164.312(a)(2)(iii) | Addressable: assess, document and adopt or implement an equivalent measure | Session lifetime and inactivity behavior set in flows or providers; confirm the settings in your version | Saved configuration, test results showing sessions end, written rationale for the chosen timeout |
| Person or entity authentication, 164.312(d) | Standard with no separate implementation specification | Authentication flows with password and MFA stages verify the claimed user before a session starts | Flow configuration export, sign-in logs showing stages passed, failed attempt records |
| MFA for ePHI access (proposed rule) | Proposed January 2025, not final (90 FR 898) | MFA stages bound to the flows used by each ePHI application; confirm coverage for every system | Stage bindings per application, MFA enrollment report, list of any exceptions with approval |
| Emergency access procedure (access control standard) | Required (Appendix A to Subpart C) | Process gap: sign-in depends on authentik, so plan access to ePHI systems if it is unavailable | Written emergency access procedure, test records, custody log for break-glass credentials |
| Sign-in and authorization events | Supports 164.312(a)(1), 164.312(d) and assessor review | Event logs record sign-ins, failures and authorization decisions; confirm retention and export in your version | Log export to your monitoring platform, retention settings, sample of recorded events |
What audit evidence an authentik deployment leaves
A HIPAA reviewer will ask who could reach ePHI, how those users were identified and how sessions ended. An authentik deployment leaves evidence for each answer, but the records sit in different places: the user store, the configuration, the event log and the change history. Collect them on purpose before an assessment.
Unique user records and identifiers
Each person who reaches an ePHI system should have one authentik user account with a stable username and a unique internal identifier. Shared or generic accounts defeat the unique user identification requirement in 45 CFR 164.312(a)(2)(i), so export the user list and check for duplicates, service accounts used by people and accounts with no owner. Confirm how your identity sources map each record, especially if users arrive from an upstream directory.
Group and policy bindings
Access to each ePHI application depends on which groups and policies are bound to its application or provider. A reviewer will compare those bindings with the access rights your workforce policy grants under 164.308(a)(4). Export the bindings for every application that touches ePHI and keep a dated copy, so you can show who could reach the system at a given time, not only today.
MFA enrollment and event records
Person or entity authentication under 164.312(d) needs evidence that MFA was enrolled and used. Export the authenticator enrollment state for each user and retain authentication events that show factor use and failed attempts. Ask your authentik provider or partner to confirm which authentication events the open source edition records and how long they stay in PostgreSQL before forwarding.
Session and inactivity configuration as code
The automatic logoff addressable specification in 164.312(a)(2)(iii) requires a predetermined inactivity limit, and the rule leaves the value to you. Keep the session length and inactivity settings in version-controlled blueprints or exported configuration, record the value you chose and the reason, and show that the same value applies to each ePHI application's provider. Auditors often sample this setting directly.
Policy change history
Auditors want to know who changed an access rule and when. Store authentik configuration in a Git repository with reviewed commits, so each change to a group, policy or flow has an author, a timestamp and an approval trail. Pair this with the database audit records that your version confirms, and note any change made directly in the admin interface outside that workflow.
Log forwarding and retention to a central store
Server and worker logs stay on the containers unless you forward them. Send authentik logs to a central log platform that your security team controls, set a retention period that matches your HIPAA documentation policy, and restrict who can alter or delete those records. Test one sample event from a login through to the central store before the audit, because an empty index is hard to explain later.
Configuration sequence for HIPAA access controls
This sequence turns a self-hosted authentik instance into an access control layer for ePHI systems, with one identity per person, group-bound policies, session limits, MFA and retained evidence in place before go-live.
Scope the ePHI applications behind authentik
Start by listing every system that creates, receives, maintains or transmits ePHI, including the administrative consoles used to manage them. The Security Rule's access control standard applies to those systems, so the list defines the boundary of the deployment. Record which applications support OAuth2/OIDC, SAML or LDAP, and which need a proxy outpost because they cannot speak either protocol. The output is a signed-off inventory showing each application, its protocol, its data owner and the access groups that should reach it. Confirm the inventory against your risk analysis and your access granting procedures under 45 CFR 164.308(a)(4) before configuring anything.
Choose and pin the deployment host and version
Decide where the authentik server, worker and PostgreSQL run. The Docker Compose guide positions Compose for test setups and small-scale production and calls for at least 2 CPU cores and 2 GB of RAM. The Kubernetes guide installs with Helm and recommends a separately managed PostgreSQL for production, since the bundled database is intended for demonstration and testing. Pin the release to a version listed as supported in the security policy, currently 2026.5.x or 2026.8.x. If you are upgrading from a release before 2025.10, review that release's notes first, because authentik removed Redis and moved its functions to PostgreSQL, with roughly 50% more PostgreSQL connections to plan for. Done means the host, database and version are recorded in your configuration repository.
Create one identity per person without shared accounts
Provision a unique user for each workforce member, and map each one to the same identifier your HR or directory system uses. Shared or generic logins cannot satisfy the unique user identification implementation specification in 45 CFR 164.312(a)(2)(i). Disable default or bootstrap accounts after an administrator account bound to a named person exists, and document who may create users. If an upstream directory is the source of truth, confirm how authentik receives and retires accounts, since joiner and leaver handling drives whether access is removed promptly. Done means a user list reconciles with the HR roster, with no accounts marked as shared.
Bind applications to groups through policies
Create groups that mirror the minimum necessary roles for each ePHI application, then attach those groups to the application's authorization policy in authentik. Users outside the group should receive a denial rather than a login into the clinical system. This is where the access control rule in 45 CFR 164.312(a)(1) is put into practice, since only persons granted access rights under the access authorization standard may reach the data. Test each application with one user from every group and one user outside it, and keep the test results. Done means every ePHI application has a documented group binding and a passing negative test.
Set inactivity timeouts for automatic logoff
Configure session lifetime and inactivity limits in the authentication flow and in each application's session settings. The rule requires electronic procedures that end a session after a predetermined time of inactivity, but it does not set that time, so your security officer must choose the value and document the reasoning. Automatic logoff is an addressable specification, so if you adopt a different measure, record why. Verify the setting by leaving a test session idle and confirming that the next request requires re-authentication. Done means each timeout value is written down, tied to a risk decision, and proven by a test.
Enforce MFA for every ePHI application and administrator
Attach an MFA stage to the authentication flow for each ePHI application and for every administrative account, and confirm that users cannot skip it through an alternate flow or protocol client. Verification of the person or entity seeking access is required under 45 CFR 164.312(d). Note that the January 2025 proposed update would require MFA across relevant technology assets, but that proposal is not final, so treat it as a planning input rather than a current requirement. Check whether LDAP or RADIUS clients connected to these systems can present a second factor, and document any that cannot along with compensating controls. Done means a login attempt without a second factor fails for each protected application.
Forward authentication logs to your log platform
Send authentik event logs to the centralized logging platform your organization already operates, and make sure login successes, failures, policy denials, lockouts and administrative changes are captured. These records are the evidence a reviewer will examine when checking unique identification, access and authentication controls. Confirm retention with your compliance lead, and confirm which events your installed version emits, since enhanced audit logging is an enterprise-only feature on the authentik pricing page. Test the pipeline by generating a failed login and a policy denial and finding both in the log platform. Done means the test events arrive with user identity and timestamps intact.
Version the configuration and retain the evidence
Store the blueprints, application definitions, group bindings, flow settings and timeout values in a version-controlled repository, and tie every change to a reviewed request. Keep the access inventory, test results, timeout decision and MFA configuration with the change history, so you can show what was in force on a given date. Assessors and OCR investigators look for documented procedures, and the Security Rule's documentation standards in 45 CFR 164.316 apply to these records. Done means a reviewer can rebuild the current configuration from the repository and match it to the signed-off inventory.
How the identity layer sits between users and ePHI systems
The identity layer is a separate system that sits in front of every application holding ePHI, and it should be deployed as one. In a self-hosted authentik deployment, the server container runs core along with an embedded outpost, the worker container runs background tasks, and PostgreSQL stores all configuration and data except uploaded files. Every login decision, MFA challenge, group membership check and session timeout is made by this stack, so its access to the database, its admin accounts and its logs become part of your Security Rule scope. Before any application is connected, confirm where each container runs, who can reach the PostgreSQL instance, and whether the database is separately managed. The Kubernetes guide recommends a separately managed PostgreSQL for production, and the bundled database is intended for demonstration and testing.
Each application that holds ePHI receives identity through a specific authentik provider. OAuth2/OIDC and SAML cover applications that can speak those protocols, LDAP covers directory-bound clients, the proxy provider covers applications that cannot, and RAC covers remote access to internal hosts. Each provider choice determines where the access decision is enforced and what the application can trust. For a clinical or back-office system, record the provider type, the application that consumes it, and whether the application still keeps its own local accounts. Local accounts that bypass the identity layer are the first gap an assessor will look for in the unique user identification and automatic logoff controls.
Trust boundaries should separate the identity deployment from the systems it protects. Place authentik on its own network segment, restrict administrative access to a small group that does not use the same accounts for clinical work, and limit which networks can reach the LDAP and RADIUS ports if you expose them. The protected applications should accept identity only from authentik, not from arbitrary headers or direct logins. Confirm these boundaries with a network diagram and a firewall review before go-live, because the identity service will be the most sensitive system in the environment.
Questions buyers ask about HIPAA and authentik
Does HIPAA certify authentik or a HIPAA-compliant deployment?
No. There is no HIPAA certification, and no vendor or deployment can receive one that counts as HIPAA compliance. HHS stated in its 2003 FAQ that no Security Rule standard requires an entity to certify compliance, that HHS does not endorse or recognize private certifications, and that such certifications do not prevent HHS from later finding a violation. The practical question is whether your own risk analysis, configuration and records show that the access controls work as you describe them. Covered entities and business associates carry that obligation, and the HHS Office for Civil Rights enforces it through complaints, compliance reviews and audits. DeployOpen prepares systems, controls and evidence for assessments but does not issue audit reports, attestations or certifications.
What does a HIPAA-focused authentik implementation cost, and what drives it?
Cost depends on written scope, which DeployOpen quotes before work starts. The main drivers are the number of applications that hold ePHI, the number and type of providers (OAuth2/OIDC, SAML, LDAP, proxy), how MFA is designed by group and application, the evidence process you need, and the hosting model for authentik and its PostgreSQL database. Ask whether the quote is one-time or recurring. Setup is one-time; support, upgrades and continuous testing are available as retainers. Licensing also matters. The authentik pricing page lists an Open Source edition at no charge, an Enterprise edition at $5 per user per month billed annually plus $0.02 per external user per month, and Enterprise Plus starting at $20k annually. Features such as mTLS client certificate authentication, password history and enhanced audit logging appear on the Enterprise list, so confirm which ones your controls depend on before you choose an edition.
How long does a HIPAA access control project take?
Duration depends on scope, and DeployOpen gives a timeline only in the written scope agreed before work starts. Projects with a few applications and standard MFA take less time than projects that integrate many systems holding ePHI, migrate existing users from another identity store, or need detailed evidence collection. The sequence usually starts with an inventory of systems that create, receive, maintain or transmit ePHI, followed by provider configuration, MFA and session policy, testing, and documentation. Ask any vendor, including DeployOpen, to show the phases, the client actions in each phase and the acceptance criteria. Ask how upgrades and the operations handover are scheduled, since authentik release notes and PostgreSQL changes can affect a live environment.
What does our team need to provide for an authentik engagement?
Expect to supply several roles. System owners for each application holding ePHI must confirm which users and groups need access, and must approve session and MFA settings. Your identity team must provide directory data, group structures and the rules for joiners and leavers. Your change management process must approve production changes. Your security or compliance lead must review the risk analysis, the access policies and the evidence list. Your infrastructure team must provide the hosting environment, database service, backups and network paths. Where DeployOpen accesses systems or data that include ePHI, a business associate agreement is normally needed under 45 CFR 164.314 before work starts. Confirm this with your privacy or legal team for your specific engagement.
Can our own team deploy authentik for HIPAA access controls without a partner?
Yes, if you have the skills in-house. A security engineer familiar with OIDC, SAML and LDAP provider configuration, PostgreSQL operations, reverse proxies and container or Kubernetes deployment can build and run the environment. The Docker Compose guide suits test setups and small-scale production, while the Kubernetes guide recommends a separately managed PostgreSQL for production. Your team also needs to write the access rules, test MFA enrollment and recovery, document session timeouts for automatic logoff, and collect logs for audit. The main risk is not the installation but the documentation and ongoing operation, including upgrades, which must follow the sequential rule and release notes. Decide early which parts you will own after go-live.
What would the proposed HIPAA MFA requirement change for authentik deployments?
If finalized, the January 2025 proposed update to the Security Rule would require multi-factor authentication on all technology assets in relevant electronic information systems, with limited exceptions. It was proposed, not final, as of October 2026 (90 FR 898). The Unified Agenda lists it under Long-Term Actions with final action projected for July 2027. For authentik, this would mean MFA enforced through flows and policies for every application in scope, with exceptions documented and justified. Today, the Security Rule already requires procedures to verify that a person or entity seeking access is the one claimed under 45 CFR 164.312(d), so MFA is a strong design choice even without the rule change. Track the Federal Register and reginfo.gov entry for RIN 0945-AA22 before you finalize your design, and confirm the final text with your counsel.
Does authentik itself need a HIPAA business associate agreement?
Authentik is open-source software that you run in your own infrastructure, so the authentik project does not host your ePHI. Your obligations depend on who hosts, operates and can access the environment. If you use a cloud provider, data center or managed database service to run authentik, confirm with that provider whether it signs a business associate agreement and what its service terms cover. If DeployOpen works on systems that access ePHI, a business associate agreement with DeployOpen is needed where applicable, which should be confirmed before access begins. Under 45 CFR 164.314(a)(2)(i), a business associate contract must require compliance with the Security Rule, flow the same terms down to subcontractors that handle ePHI, and report security incidents to the covered entity.
Why the penalty range makes access evidence matter
The penalty range is the reason access evidence deserves design time before an audit or complaint arrives. The HHS Office for Civil Rights (OCR) 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 the Security Rule provisions most relevant to hacking and ransomware, so access control is a likely area of inquiry. For penalties assessed on or after January 28, 2026, the inflation-adjusted civil money penalty runs from $145 per violation (no knowledge) to $2,190,294 per violation (uncorrected willful neglect), with a calendar-year cap of $2,190,294 under 45 CFR 102.3. Confirm the current figures against the eCFR text of 45 CFR 102.3 before using them in a board paper, since the adjustment is updated periodically.
Access evidence does not prevent an investigation or change how a penalty is calculated by itself. What it does is shorten the factual questions OCR and counsel must answer. For an authentik deployment, that means being able to show which unique user identifier performed an action, which group or policy granted the access, whether MFA was enforced at sign-in, and how long a session could remain idle before it ended. A covered entity that can produce these records quickly is in a stronger position to describe its safeguards and what it did when something went wrong. A covered entity that cannot is left reconstructing events from application logs that may not agree with each other.
Treat the evidence list as a planning input. Before go-live, ask your security and compliance leads which questions they expect OCR to ask about each ePHI application, then check that authentik's event log, provider assignments and flow configuration can answer them. Confirm with your own counsel how long your organization must retain these records and where they will be stored. The retention and export settings you choose are decisions for your organization, and they should be written down before an incident, not after one.
How DeployOpen scopes and delivers HIPAA access control configuration
DeployOpen plans, implements, hardens, documents and supports self-hosted open-source platforms inside your own infrastructure, including authentik. For HIPAA access controls, the work centers on a written scope that maps authentik configuration to the access control, automatic logoff and authentication requirements your systems must meet, with evidence your own team and assessors can review.
How we scope
- Inventory the ePHI systems that need authentik sign-in and list the user populations and roles for each.
- Map unique user identification, session timeout and MFA requirements to specific applications, groups and flows.
- Record the protocols, hosting location and deployment model in a written scope before any build work starts.
How we build
- Configure providers, applications, groups and access policies in the agreed authentik deployment in your environment.
- Set session timeouts and re-authentication rules for each application, and test them against the documented settings.
- Test MFA enrollment and enforcement for every in-scope application, including the failure and lockout paths.
How we hand over
- Document the configuration, access policy decisions and the reasons behind any addressable specification choices.
- Define the audit log events, retention settings and review queries your team will use as evidence.
- Walk your administrators through runbooks for onboarding, offboarding, policy changes and emergency access.
How we support
- Offer ongoing support, upgrades and continuous testing as a retainer after the initial handover.
- Plan authentik version upgrades against the supported release lines published in the project security policy.
- Confirm with your compliance team which findings belong to a HIPAA assessment, since DeployOpen does not issue attestations.
