164.308(a)(4)(ii)(B) Access authorization: requirements and evidence

What HIPAA access authorization requires and why it is hard to evidence

When an auditor or a customer questionnaire asks how access to ePHI is granted, the answer has to be a written policy with a procedure behind it. Under 45 CFR 164.308(a)(4)(ii)(B), the Security Rule calls for policies and procedures for granting access to electronic protected health information through a workstation, transaction, program, process or other mechanism. The specification is addressable, not optional. Under 45 CFR 164.306(d)(3), you must first assess whether it is reasonable and appropriate for your environment. If it is, you implement it. If it is not, you document why and adopt an equivalent alternative measure that is reasonable and appropriate. Either way, the decision itself is evidence, so an unrecorded judgment is the same as no judgment at all.

The risk this specification addresses is unauthorized access and excessive access: a workforce member, contractor or service account reaching ePHI that their role never needed. Most organizations can show that accounts exist and that logins are logged. What they usually cannot show is the basis on which each access right was approved: who may approve it, what role or job function justifies it, which systems and data sets it covers, and what minimum necessary scope was applied. The gap is almost always the approval basis rather than the tooling. A directory or identity platform can enforce whatever rule you give it, but it cannot invent the rule.

Before you buy or configure anything, write down the approval logic. Name the approvers for each class of ePHI system, map roles to the access they justify, and state the exceptions process. Then confirm with your privacy and security leads that the policy matches the risk analysis from 164.308(a)(1)(ii)(A). Ask any implementation partner or software vendor to show where each approval decision is recorded and who signed it. For the technical side, NIST SP 800-66 Rev. 2 gives sample questions you can use to test whether your access authorization policy is complete.

Which systems, people and vendors fall under access authorization

Access authorization applies wherever ePHI can be reached, so the scope follows the data flows your risk analysis maps, not the org chart. The cards below cover the decisions that change how much policy, approval and review work you take on.

ePHI systems and their data stores

Start with the systems that create, receive, maintain or transmit electronic protected health information, including databases, file shares, backups and archives. Each store needs a named owner who can approve who gets access. Check whether copies exist outside the primary system, such as exports, reporting databases or analytics extracts, because each copy creates its own authorization decision. Confirm the list against the current risk analysis rather than memory.

Workstations and devices with ePHI access

The specification names access to a workstation as a mechanism to control, so endpoints that open ePHI systems are in scope. Clinical workstations, shared kiosks, laptops used off site and mobile devices each need a rule for who may log in and under what conditions. Ask whether a workstation authorization is tied to a person, a role or a shared account, since shared accounts make authorization decisions hard to evidence.

Applications, transactions and processes

Access also runs through applications, transaction types and automated processes such as interfaces, batch jobs and integration service accounts. A workforce member may be authorized for the chart but not for a billing transaction that exposes the same records. Map which transactions and programs reach ePHI, then decide who approves each one. Service accounts need an owner, a documented purpose and a review schedule just like people do.

Workforce roles and approvers

Authorization policy must say who approves access to each system and on what basis, such as job role, clinical need or supervisor sign-off. Define the approver for each role, the evidence they must record, and what happens when the approver leaves. Confirm that approvers have enough knowledge of the data to judge the request, and that no one approves their own access. Role definitions should align with the minimum necessary approach in the Privacy Rule.

Clearinghouse functions, if present

If your organization includes a health care clearinghouse, the separate required specification for isolating clearinghouse functions applies alongside this one. Access authorization must then keep clearinghouse ePHI away from workforce members in the rest of the organization unless their role justifies it. Ask whether shared identity systems or shared administrators create a path around that separation, because a shared directory can undo an otherwise sound policy.

Business associates and managed service providers

Vendors with administrative access to ePHI systems, such as managed IT providers, hosting staff and support engineers, are part of the authorization scope. Decide which vendor accounts exist, who in your organization approves them, how they are time-limited, and how their activity is logged. Your business associate agreement should match these controls. Vendor access is a common gap because accounts are created for projects and never removed.

How the access authorization policy decides who gets access

The access authorization policy answers one question before any account is created: who may approve access to ePHI, and on what basis. The policy should name the approver for each system or data set, such as a data owner, a department head or the security official, and state the criteria the approver applies. Those criteria are usually a job role, a documented job function, or a specific need for a defined task, and each should be tied to the minimum necessary approach that the Privacy Rule expects. The policy also has to say which access mechanisms it covers. A workstation login, an application role, a database query path, a batch process and a service account are all ways to reach ePHI, and an approver should not be left to guess whether a grant to one of them is covered.

Authorization is the decision. Establishment and modification under 164.308(a)(4)(ii)(C) is the work that carries the decision out: creating the account, assigning the role, recording the grant and later changing or removing it. The rule does not prescribe a model such as role-based access control, attribute-based access control or per-user grants. The organization chooses a model that fits its systems and documents it, and the risk analysis should show why the chosen model keeps access proportionate to need. Confirm with your own environment which model applies to each system, because a single model rarely fits an EHR, a file share and a cloud reporting tool equally well.

Exceptions are where many policies fail. The policy should define who can approve a temporary or emergency grant, how long it lasts, what compensating checks apply, and where the exception is recorded for later review. Keep a short list of decisions to make now: name the approver for each ePHI system, write the criteria in terms your workforce can apply, decide how exceptions expire, and confirm that the approval record can be produced for an assessor. Open-source identity tools such as authentik, Keycloak and midPoint can enforce these decisions, but they do not write the policy for you, and the approval basis must still come from the organization.

How an assessor tests access authorization

This table sets out how an assessor typically tests the access authorization policy under 164.308(a)(4)(ii)(B), what evidence they ask for, and where organizations most often fail. Read each row as a test step paired with the proof it needs. The main takeaway is that a written policy alone rarely passes; the assessor will trace individual grants back to a documented approval and an addressable decision.

Test step	Evidence requested	Common finding
Review the written access authorization policy	Current policy naming who approves ePHI access, the approval basis (role, job function, need to know) and the systems covered	Policy exists but names no approver or basis for approval
Sample granted access requests	Access request tickets or forms for a selection of workforce members, with dates, requested systems and the access level granted	Access granted without a request record, or requests that do not state the ePHI systems involved
Check each sampled grant against an approval	Signed or system-recorded approval by the person the policy designates, dated before the access took effect	Approvals given verbally or by chat message, with no retained record
Confirm approvals match the policy's basis	Evidence that the role or justification on the request matches the policy's criteria for that access level	Approver used a role that the policy does not authorize for ePHI
Review the addressable assessment	Documented decision on whether access authorization is reasonable and appropriate for the environment, tied to the risk analysis	Addressable decision undocumented or never revisited after systems changed
Review any alternative measure	Written rationale for why the specification was not implemented as written, plus the equivalent measure and evidence it operates	Alternative measure described but not implemented, or no rationale recorded
Interview designated approvers	Approvers can state what they check before approving, who they report to and how exceptions are handled	Approvers unaware they hold the role, or applying informal criteria
Trace approvals into the directory or identity system	Configuration or export showing that approved access is provisioned, with the approval reference where the system supports it	Approved access differs from what was granted, or accounts exist with no approval on file

Implementing access authorization step by step

This sequence turns the addressable access authorization specification into a documented decision process, from knowing where ePHI can be reached to proving who approved each grant and why. Each step produces an artifact an assessor can inspect.

Inventory ePHI access points
Start from the risk analysis and list every place ePHI can be reached: workstations, applications, databases, transaction interfaces, reporting programs and administrative consoles. For each entry, record the system owner, the data classes it holds and the roles that currently reach it. The output is an access point inventory that the security official signs off. You know this step is done when every system named in the risk analysis appears in the inventory with an owner.
Decide and document the addressable assessment
Access authorization is an addressable specification, so the organization must decide whether it is reasonable and appropriate to implement it as written. Ask the security official and compliance lead to assess the policy against the inventory and the risk analysis. If it is adopted, document the decision. If it is not, record why and the equivalent alternative measure you will use. The output is a signed assessment record. Keep it with the policies, since the documentation standard applies to it.
Define approvers and approval basis by role
Name who may approve access to each access point in the inventory, and the basis for approval, such as job function, supervisor attestation, data classification or a completed clearance step. Keep approvers separate from the people who will receive the access where your staffing allows. Avoid approval chains that depend on one person who cannot be reached. The output is an approval matrix that maps each access point and role to its approver and criteria. Confirm the matrix with the system owners before it goes into the policy.
Write the procedure and request workflow
Turn the matrix into a written procedure covering how a request is raised, who reviews it, what evidence is attached and how a denial is communicated. Specify the channel, such as a ticketing system or identity governance workflow, so that the request itself is recorded. Describe the emergency or break-glass path separately, with its own approver and after-the-fact review. The output is an approved access authorization procedure and a request template. Confirm the workflow tool can retain requests long enough for your retention policy.
Record the decision for each grant
For every access grant, capture the requester, the approver, the access point, the role or justification, the date of decision and any conditions. Where identity tooling is used, link the approval record to the account that was created so the two can be matched later. Denials are recorded too. The output is an access authorization log that an assessor can sample from. Check periodically that approvals in the log match the matrix and that no grant exists without a recorded decision.
Automate grants where identity tooling fits
Self-hosted identity platforms can enforce the approved decisions instead of relying on manual account setup. An identity provider such as authentik can limit which applications each user reaches through its providers. FreeIPA can centralize Linux and UNIX access, and Keycloak can federate users from an existing LDAP or Active Directory directory. midPoint can create and update accounts on connected systems from role assignments. Confirm each platform's capabilities against your environment before relying on them, and test that a grant cannot be made outside the approved matrix.
Review the policy after changes
Revisit the access authorization policy when systems, roles, vendors or the risk analysis change, and on whatever schedule your risk analysis sets. Compare the current inventory with the matrix, remove approvers who have left, and check that new applications were added to the inventory before they went live. The output is a dated review record with any revisions approved by the security official. This feeds the evaluation standard, so keep the record with the other periodic reviews.

How identity tools can enforce and evidence approvals

Keycloak user federation connects to an existing LDAP or Active Directory server and synchronizes users into Keycloak, so application sign-in can use accounts that already live in the corporate directory. Where your approval workflow places the grant in the directory, Keycloak can carry that grant into applications without a second account store. This reduces the number of places where an access decision can drift from the approved record.

Evidence produced: Directory group membership and synchronized user records that show which accounts an application can accept, along with the sync configuration that defines how they are imported.
Evidence it does not produce: Who approved each grant and on what basis. The approval record usually sits in a ticketing or identity governance system.
Decisions you still own: Which groups map to which application roles, who may change those mappings, and whether federated users need additional approval before access.
Configuration to review: Sync scope, attribute mapping and whether removed directory accounts are disabled in Keycloak as well.
Common gap: Local Keycloak accounts created outside the directory, which bypass the approval path entirely.

Confirm the exact federation and sync behavior for your Keycloak version and directory type before relying on it in an assessment, and keep the approved group definitions in a document the assessor can read.

Evidence that satisfies access authorization

Access authorization is tested through paper and records together: a written policy, a clear approver matrix, and proof that each grant followed the rule. The cards below cover the evidence set an assessor or OCR investigator would expect to see, and how to keep each item current between reviews.

Written access authorization policy

The policy states who may approve access to ePHI, through which mechanisms (workstations, applications, transactions, programs or processes), and on what basis, such as job role and documented business need. It should be dated, versioned and approved by the security official. Check that it names the workstation, application and data classes it covers, and that the procedure matches what staff actually do. Review it at least when systems, roles or the risk analysis change.

Approver matrix by role

The matrix maps each role to the access it may request and the person or role who must approve it, including approvals for clinical, billing, administrative and privileged accounts. Segregation matters: a requester should not approve their own access. Confirm the matrix against the directory group structure, since a matrix that no longer reflects current roles becomes an audit finding. Keep dated copies so you can show which version governed a given grant.

Approval records for sampled grants

Assessors usually select a sample of recent access grants and ask for the request, the approval and the reason for each. A complete record names the requester, the access granted, the approver, the date and the basis under the matrix. Store these in a ticketing or identity workflow system with retention set by your policy. Test your own sample quarterly so gaps appear before an auditor finds them.

Addressable assessment and alternative measures

Because access authorization is addressable, the file should show a documented decision on whether it is reasonable and appropriate for your environment. If an element is not implemented, the record must explain why and describe the equivalent alternative measure, with reasoning tied to the risk analysis. Ask counsel or your security official to sign off, and revisit the decision when environments change. A vague statement that access is controlled will not satisfy this item.

Provisioning logs matched to approvals

Provisioning logs show what the identity system actually granted and when. An assessor will compare them with approval records to confirm that every grant had a matching, valid approval and that no account received access outside the matrix. Tools such as midPoint can record provisioning actions, and directory logs show group membership changes. Confirm that logs are retained, protected from edit, and reviewed, since unexplained grants are a common gap.

What meeting access authorization costs in money and effort

Meeting 164.308(a)(4)(ii)(B) costs more in people and process than in software. The largest items are the time security, compliance and system owners spend writing the access authorization policy, deciding who may approve access to each workstation, transaction, program or process that touches ePHI, and agreeing the basis for each approval, such as job role, data sensitivity or the minimum necessary standard. Those decisions are mostly one-time work, although they are revisited whenever the risk analysis changes or a new system holding ePHI goes live. Identity tooling is an optional cost. Open-source options such as authentik, FreeIPA, Keycloak and midPoint remove license spend, but they still need an engineer to configure providers, directory federation and provisioning rules, test them, patch them and keep them running. That configuration and operations effort is the real budget line, and it is easy to underestimate.

Some costs recur. Each approval, denial and modification should leave a record that ties the request to the authorization policy, and someone must keep those records complete. Periodic reviews of who holds access, which the access establishment and modification specification in 164.308(a)(4)(ii)(C) builds on, consume time every cycle. Evidence upkeep, such as exporting directory and provisioning logs and keeping the approval matrix current, is easy to skip and expensive to reconstruct later. Outside help can enter at several points: drafting the policy, configuring the identity stack, or having an independent assessor test the process. The organization owns its safeguards in every case. An implementation partner prepares systems and evidence, and only an independent assessor can give an outside opinion on them.

When requesting a quote, ask the provider to separate one-time from recurring work and to name each deliverable. Useful items include the approval matrix and policy drafting, the identity architecture and integration tasks for each connected system, provisioning and reconciliation rule design, testing and evidence export procedures, and handover training for your staff. Ask who operates the platform after go-live, what support is included, and how changes to the authorization policy will be handled. Confirm which systems are in scope before pricing, because each additional application or workstation group adds configuration work. Finally, ask what the quote excludes, such as licensing for any commercial components, hosting in your own environment, and any independent assessment you choose to commission.

Cost components for access authorization

This table compares the main cost components of meeting 164.308(a)(4)(ii)(B) access authorization, showing who is paid for each, whether it is one-time or recurring, and what drives it up. Read it as a checklist to request line items in a written scope, since no prices are published here. The main takeaway is that the policy and evidence work recurs with every access review, so open-source tooling mainly reduces license spend and not the ongoing effort.

Cost component	One-time or recurring	What drives it and how to keep it down
Internal policy and assessment time	One-time setup, then recurring review	Number of systems holding ePHI and the number of role types. Keep the authorization policy short, tied to named roles and reviewed on a fixed cycle.
Tooling or licenses	Recurring if commercial	Commercial identity and provisioning licenses scale with user counts. Open-source options such as authentik, FreeIPA, Keycloak and midPoint remove license spend, though hosting still applies.
Engineering to integrate approvals	One-time, with later change requests	Number of applications and directories to connect, and whether approvals run through a ticketing workflow. Reuse one approval pattern across applications.
Evidence upkeep	Recurring	Frequency of access reviews and how many approval records must be retained. Export approval and provisioning logs automatically rather than collecting them by hand.
External review or testing	Periodic, as scoped	Depth of the scope, such as whether access paths are tested in a penetration test. Confirm in writing which access paths and sample sizes are included.
Assessor sampling time	Per assessment cycle	Number of access grants the assessor selects for testing. Clear, consistent approval records shorten sampling and follow-up questions.

Where organizations fall short on access authorization

Access authorization is addressable, so auditors look for a documented decision, a named approver and a clear basis for every grant. The gaps below are where that chain usually breaks, and each card names the check that closes it.

Approvers are not defined

Many policies say access must be authorized but never name who may approve it for each system holding ePHI. When a request reaches the EHR, the file share or a billing platform, staff cannot tell whether a department head, the system owner or the security official signs off. Check that each ePHI system has a named approver or approving role, and that the policy says what happens when that person is unavailable.

Basis tied to job title

Approving access by job title, such as granting every nurse the same records, tends to exceed what the role needs. The specification asks for a basis for access, and the minimum necessary approach in the Privacy Rule points toward need. Check whether approvals reference the specific systems, data sets and functions a person requires, and whether role templates were built from the risk analysis rather than copied from an org chart.

Addressable decision never documented

Teams often implement access approvals without recording why the specification was judged reasonable and appropriate, or why an alternative measure was chosen instead. An auditor reviewing the decision will look for that written assessment. Check that the risk analysis or a dated decision record states whether the specification applies, what was implemented, and what equivalent measure covers any gap.

Approvals not linked to provisioning

An approval in a ticket means little if the account in the identity store was created by hand, with different rights. Approval records and actual access then drift apart, and the policy cannot be shown to govern anything. Check that each granted right traces to an approval record and that provisioning tools, such as midPoint or a directory-based flow, create accounts only from approved requests. Confirm that the approval reference is kept with the account.

Vendors with administrative access outside policy

Managed IT providers, billing companies and remote support vendors often hold administrative access through shared accounts or standing vendor logins that never pass the internal approval path. Those grants are still access to ePHI. Check that every vendor account is covered by the same approver, basis and record requirements, and that any business associate terms reflect who may approve vendor access.

Questions buyers ask about access authorization

Can we skip access authorization because it is addressable?

No, not without a documented decision. Addressable does not mean optional to ignore. Under 45 CFR 164.306(d)(3), you must first assess whether the specification is reasonable and appropriate for your environment. If it is, you implement it. If it is not, you must document why and put in place an equivalent alternative measure, provided that alternative is reasonable and appropriate. In practice, almost every organization that grants access to ePHI already has some authorization logic, such as a manager approving a request or a role assigned at hire. The gap auditors look for is the absence of a written policy that explains who approves access and on what basis. Record your assessment, the reasoning and any alternative in your risk analysis so the decision can be reviewed later.

How much effort does access authorization take to document and run?

The effort is mostly in writing decisions and keeping them current, not in the technology. The main work items are defining the access tiers tied to job roles, naming the approvers for each tier, specifying the evidence required for each request, and deciding what triggers a new approval. The effort rises with the number of systems that hold ePHI, the number of distinct roles, and how many applications still rely on local accounts. It falls when a central identity source already exists. Ask your implementation partner for a written breakdown of which systems are in scope, which roles are modeled, and which work is one-time (policy design, role mapping, initial approvals) versus recurring (new requests, reviews, approver changes).

Are open-source identity tools enough to meet this specification?

Tools can enforce and record access decisions, but they cannot write your policy or make the risk judgment for you. Open-source components such as authentik, which acts as an identity provider through OAuth2, OpenID Connect, SAML, LDAP, RADIUS and proxy providers, let applications delegate sign-in so access is granted in one place. FreeIPA provides single sign-on for Linux and UNIX environments through an MIT Kerberos KDC. Keycloak can federate users from existing LDAP or Active Directory servers, so accounts managed in your corporate directory are used for application sign-in. The authorization policy itself, including who approves what, must be written and owned by your organization. Confirm each tool's current capabilities and licensing against its own documentation before you rely on it.

How does provisioning tie approved access to the accounts that get created?

Provisioning connects the approval record to the accounts on each system, which is where many authorization programs fail. midPoint creates, updates and deletes accounts on connected systems based on user changes and role assignments. It keeps them aligned through provisioning, live synchronization, scheduled reconciliation and discovery, with separately defined inbound and outbound rules. Engineers should check three things: that every role maps to a documented access level, that reconciliation reports accounts that exist without an approval, and that inbound rules cannot silently grant elevated rights. Review the mapping rules with your security official before go-live, and test them against a sample of real user changes in a non-production environment.

How long does it take to put access authorization in place?

No reliable duration can be stated without knowing your scope. The timeline depends on the number of systems holding ePHI, whether roles already exist, how many approvers must agree on the policy, and whether identity sources are clean. Organizations with a documented directory and role model usually move faster than those rebuilding access from spreadsheets. Ask any partner for a written schedule tied to named milestones: policy approval, role catalog, system integration, pilot approvals, and evidence collection. A fixed-scope agreement should state what is in and out of scope before work begins, so timing reflects the agreed deliverables rather than an open-ended search.

Can an outside partner prepare the evidence for access authorization?

Yes, a partner can prepare systems, configuration records and evidence, but the organization still owns the control and an independent assessor reviews it. DeployOpen plans, implements, integrates and documents self-hosted open-source platforms inside your own infrastructure, so it can build the identity stack, the role model and the approval workflow with your team. It does not issue audit reports or attestations. Those come from independent assessors. Before engaging anyone, confirm who writes and approves the policy, who keeps the approval records, and which artifacts you will hand to your assessor, such as the addressable decision, the approval policy, sample access grants and review logs.

Primary sources for the access authorization requirement

Start with the regulation itself. The access authorization specification sits in 45 CFR 164.308(a)(4)(ii)(B), and the eCFR text of 164.308(4)(ii)(B)) is the wording an assessor or OCR investigator will quote. Read it for the three things it asks for: written policies and procedures, a defined way of granting access to ePHI through a workstation, transaction, program, process or other mechanism, and the expectation that access is granted on a stated basis. Note that the specification asks for policies, not a particular tool, so the document that proves compliance is your access authorization policy and the records showing it was followed.

Next, read the eCFR text of 164.306, which governs how addressable specifications work. This is where the decision sits for access authorization. Your organization must assess whether the specification is reasonable and appropriate for its environment. If it is not, the rule requires a written explanation and an equivalent alternative measure where one is reasonable. Confirm with your own risk analysis which roles, systems and data types make the specification reasonable, and record that reasoning before an auditor asks for it.

For implementation detail, use NIST SP 800-66 Rev. 2, published February 2024. It lists key activities and sample questions for each standard, including information access management. HHS treats it as informational rather than binding, so cite it as a guide to how you built the control, not as the requirement itself. Pair it with your own documented decisions on who approves access, what basis they use, and how the approval is recorded.

How DeployOpen works on this

DeployOpen plans, implements and documents self-hosted open-source identity and provisioning platforms inside your own infrastructure, so the access authorization policy and its supporting evidence are built around your systems. Your organization owns the policy and the approval decisions, and DeployOpen prepares the systems and records that show how access is authorized.

How we scope

We agree in writing which systems, applications and access paths fall under the 164.308(a)(4)(ii)(B) access authorization work.
We confirm with you who must approve access to ePHI, the basis for approval, and which roles your risk analysis identifies.
Engagements are fixed-scope, with deliverables and timelines agreed before work starts, and a quote follows from that written scope.

How we build

We configure the identity provider so applications delegate sign-in, using the provider types your environment needs.
We connect existing directories such as LDAP or Active Directory so accounts managed in your corporate directory drive application access.
We set up provisioning rules that create, change and remove accounts from approved role assignments, and we test those rules before go-live.

How we hand over

We document the authorization workflow, approver roles and role-to-access mappings in a form your security official and auditors can review.
We deliver test records showing approved requests, denied requests and account changes, so you can confirm the workflow operates as written.
We hand over configuration, runbooks and evidence exports, and we confirm with your team which records you need to retain.

How we support

Ongoing support, upgrades and continuous testing are available as retainers when your access model changes.
We can rerun authorization tests after platform upgrades or new applications join the identity provider.
Your organization keeps ownership of the policy, and any independent assessment of your access controls is performed by a qualified assessor you select.