164.312(a)(2)(iii) Automatic logoff: requirements and evidence

What HIPAA automatic logoff requires and why auditors still ask about it

An auditor or customer who asks about automatic logoff wants proof that an idle session on a system holding ePHI ends on its own. Under 45 CFR 164.312(a)(2)(iii), the rule requires electronic procedures that terminate an electronic session after a predetermined time of inactivity. It does not say how long that time should be. Your organization sets it through its risk analysis, and the answer must be written down, justified against the threats you identified, and applied consistently. The specification is addressable, which means you must assess whether it is reasonable and appropriate for each system. If it is not, you document why and implement an equivalent alternative measure that is reasonable and appropriate (see 45 CFR 164.306). Doing nothing is not an option that the text allows.

The risk is ordinary and common. A clinician leaves a workstation unlocked between patients, a browser tab with a patient chart stays open on a shared kiosk, or a web-based scheduling or billing session remains logged in on a laptop left in a car. Any of these can expose ePHI to someone who was never authorized to see it, and the audit log will show activity under a valid user ID. Shared workstations and many applications make this harder. Each application may have its own session lifetime, a single sign-on session may outlive the application session, and clinical workflows such as medication administration or imaging review can be interrupted by a timeout at a bad moment. These tensions are exactly what the risk analysis should record, including which systems you exempted or tuned and why.

There is no HIPAA certification for automatic logoff or for the Security Rule as a whole. HHS has stated that no standard requires an entity to certify compliance, so a vendor's badge or a consultant's label does not settle the question for an assessor. What persuades an auditor is a documented timeout decision per system, configuration evidence that the setting is in force, and records showing the decision was reviewed when the risk analysis changed. Confirm with your own security official which systems require a timeout, what the setting is on each, and where the evidence is kept before an audit asks for it.

Which systems, sessions and teams fall under automatic logoff

Automatic logoff applies wherever a user session can show or reach ePHI, so the scope starts with an inventory of those sessions, not with a single setting. The cards below cover the decisions that change the work and who has to agree on the timeout before it is configured.

Applications and endpoints that display ePHI

Start with the systems that hold or display ePHI, including the EHR, billing, scheduling, imaging viewers, lab interfaces and any reporting tool that exports patient data. Each one needs a documented decision on whether it can end an idle session and, if so, after how long. Check endpoints too, because a logged-in laptop or workstation can expose ePHI even when the application behind it is secured. Treat the inventory from your risk analysis as the starting list, and confirm each entry against where ePHI actually appears.

Web portals versus desktop clients

Browser-based applications and installed desktop clients often time out differently, and the session may end in the browser while the client keeps its local state open. Ask each vendor how idle detection works, whether it counts mouse and keyboard activity, and whether a timeout closes the session server-side or only hides the screen. A portal that re-prompts for a password after a timeout is a different control from one that simply clears a cookie. Record the behavior you verified, not the behavior the vendor describes.

Shared clinical workstations

Workstations in exam rooms, nursing stations and emergency departments are often shared by many clinicians who sign in and out during a shift. Here the timeout interacts with fast user switching, badge tap-in and shared-session policies, and a short timeout can drive staff toward shared logins, which conflicts with unique user identification. Decide whether the lock applies at the workstation, the application or both, and confirm that a locked session cannot be reopened by the next person without authentication.

Remote access and VPN sessions

A VPN or remote desktop session can keep an ePHI system reachable after the application session has ended, so the network layer needs its own idle rules. Confirm whether the VPN gateway, the virtual desktop broker and the remote host each enforce an idle limit, and whether a disconnected session stays logged in on the host. Mismatched limits are a common gap, so compare the three values side by side during testing.

APIs and service accounts

Automatic logoff targets interactive user sessions. API tokens, integration accounts, batch jobs and service identities are not people sitting at a screen, so an idle timeout does not usually apply to them in the same way. Those credentials still need their own controls, such as token expiry, rotation and restricted scope, which fall under access control and person or entity authentication. Document this boundary explicitly so an assessor does not read the absence of an idle timeout on a service account as a gap.

Third-party hosted systems

When a business associate hosts the application, the timeout may be a vendor-controlled setting you can request but not change yourself. Ask the vendor whether the idle period is configurable, what the default is, who can change it, and whether changes are logged. Record the answer in your contract file and in the business associate assessment, since the covered entity still answers for whether the control is reasonable and appropriate. Where the vendor cannot adjust it, document the compensating measure you chose.

Who must agree on the timeout

The timeout is a shared decision. Clinical leaders weigh patient care and interruption risk, the security official owns the risk analysis outcome, the application owner or IT team configures the setting, and the privacy or compliance lead signs off on the documented rationale. For hosted systems, the business associate's security team must confirm what it can enforce. Name one owner for each system, and record the approved value, the date and the reviewer, so the decision can be traced when policies are reviewed.

How an assessor tests automatic logoff

This table compares what an assessor checks, what evidence they ask for and where automatic logoff usually fails. Read it as a sequence: confirm the documented decision first, then sample systems to see whether the timeout actually runs. Most gaps come from settings that were never recorded or never enforced on every system holding ePHI.

Test area	What the assessor does	Evidence requested	Common finding
Documented timeout and risk analysis	Reads the written procedure and checks that the configured inactivity period traces back to the entity's risk analysis	Automatic logoff procedure, risk analysis entry covering ePHI systems, approval record	Timeout is stated nowhere, or the value has no link to the risk analysis
Addressable decision record	If no timeout is in place, checks for a documented assessment of whether it is reasonable and appropriate and an equivalent alternative measure	Signed decision memo, date, reasons, description of the alternative control	No decision recorded at all for an addressable specification
Sampling of applications	Selects a sample of EHR, portal, reporting and admin applications and tests idle sessions against the documented period	Configuration exports, screenshots of session settings, test results with timestamps	Some applications ignore the global setting or use longer vendor defaults
Sampling of endpoints	Selects workstations, kiosks and shared devices and checks screen lock or session lock after inactivity	Group policy, MDM or configuration management output, compliance scan results	Shared workstations left unlocked, or lock settings differ by device group
Settings consistency across systems	Compares the timeout values across systems, identity providers and environments such as production and disaster recovery	Side-by-side configuration inventory with owner and last review date	Settings differ across systems with no documented reason for each difference
Session persistence after close or expiry	Closes the browser, lets a token expire and attempts reuse of the session or refresh token	Test scripts, captured results, token lifetime settings from the identity provider	Sessions survive browser close, or refresh tokens extend access well past the documented period
Monitoring and review	Checks whether configuration drift is detected and whether exceptions are reviewed on a schedule	Scan reports, change records, review sign-off showing exceptions were handled	Settings are checked once at deployment and never again

How to implement automatic logoff in five steps

This sequence turns the addressable automatic logoff specification into a documented, tested timeout across every system that shows ePHI. Each step produces an artifact an assessor can inspect, from the session inventory to the review record that shows the setting still fits the risk analysis.

Inventory every ePHI-facing session
List each application, operating system, remote access service, VPN, portal and identity provider where a user or service can open a session that displays or processes ePHI. Include administrative consoles and workstations, and note whether the session runs on a shared device or a kiosk. The owner of each system confirms the list. The step is done when the inventory names every session type, its owner and whether it can be configured for idle timeout. Gaps found here usually point to shadow systems that the risk analysis should also cover.
Assess the specification and set the timeout
Record whether automatic logoff is reasonable and appropriate for each session type, using the risk analysis as the basis. The rule does not fix a time, so the chosen value must be justified by the risk to the ePHI, the access setting and the clinical or operational need for continuity. If the specification is judged not reasonable and appropriate, document why and record the equivalent alternative measure. The step closes with a signed decision record per session type that names the timeout and the reasoning behind it.
Configure each system to end idle sessions
The owner of each system applies the decided timeout in its own settings, such as application session policies, operating system screen lock and idle policies, VPN idle settings, or session lifetime settings in the identity provider. Where a platform is self-hosted open source, the configuration lives in version-controlled files so changes are traceable. Monitoring tools can help confirm the setting is still in place. Wazuh Security Configuration Assessment checks endpoint configuration against YAML policies that can be extended with custom checks, and Fleet policies can ask devices yes or no questions through osquery. Confirm with each vendor which settings the product exposes, because capability varies by product. The step is done when every system in the inventory shows the configured value.
Test enforcement across tokens and browsers
Run scripted and manual tests that confirm the session ends after the configured period of inactivity. Test how the timeout behaves with active API tokens, refresh tokens and cached credentials, because a session can end in the browser while the token stays valid. Repeat the test across the browsers and devices your users rely on, and confirm that a logged-out session cannot be resumed from the back button or a stored page. Where authentik acts as the identity provider for applications over OpenID Connect or SAML, verify that application sessions and provider sessions expire together. Keep the test script, dates, results and any failures with the owner's sign-off.
Document the setting, exceptions and review cycle
Write the approved timeout for each session type into the access control procedures and the system configuration records. List every exception, such as a clinical workstation that needs continuous access, with the compensating measure and the approver. Set a review cycle that ties the timeout back to the risk analysis, and assign an owner to run it. Confirm the review cadence with your own policies, because the Security Rule does not set one. The step is done when an assessor can trace a timeout from the risk analysis to the configured value, the test evidence and the most recent review.

How identity and endpoint controls enforce a session timeout

The fastest way to enforce automatic logoff across many systems is to move session control out of each application and into a central identity provider. When sign-in is delegated, the timeout and token lifetime are set once and apply to every application that trusts that provider. authentik is one option for this role. It acts as an identity provider for applications through OAuth2 and OpenID Connect, SAML, LDAP, RADIUS and proxy providers, so applications delegate sign-in to it rather than maintaining their own login and session logic. For Linux and UNIX hosts, FreeIPA provides single sign-on through an MIT Kerberos KDC, which lets administrators control ticket lifetimes for those environments from one place.

Before relying on this design, confirm how each product expires sessions. Check the session and token lifetime settings in the authentik and FreeIPA documentation, including whether an idle timeout exists separately from an absolute token lifetime, and whether it applies to refresh tokens. Then test it. Log in, leave the session idle for the period your risk analysis set, and confirm that the next request requires re-authentication. Also confirm that applications which keep their own session cookies, such as legacy internal tools, are not exempt. Any application that cannot delegate sign-in needs its own documented timeout and an entry in the risk management plan.

Endpoints need a matching control because a session left open on an unattended workstation is still a session. Wazuh's Security Configuration Assessment can scan monitored endpoints against YAML policies, mostly based on CIS benchmarks and extendable with custom checks, to verify settings such as screen lock configuration. Fleet policies, written as osquery queries that answer yes or no for each device, can also confirm that devices on each fleet pass a screen lock check. Ask the platform team to record which policy checks screen lock, how often it runs, and who reviews failing devices, since that record is the evidence an assessor will ask for.

Evidence that passes automatic logoff and how to keep it current

Automatic logoff is judged on whether your timeout decision is documented and whether the settings you claim are actually enforced. The cards below cover the artifacts an assessor usually asks for, and how to refresh each one between audits so the evidence still matches production.

Risk analysis entry and timeout decision

The timeout value is set in your risk analysis and risk management plan, not in the rule itself. Record the systems in scope, the session types (workstations, clinical apps, remote access), the inactivity period chosen, and the threats it addresses, such as shared workstations in clinical areas. Refresh this entry whenever systems, locations or user populations change, and at each scheduled risk analysis update.

Addressable decision memo

Because automatic logoff is addressable, you must assess whether it is reasonable and appropriate for each system. If you decide an element is not reasonable, the memo must explain why and describe the equivalent alternative measure you adopted. Ask your reviewer to confirm that every system with ePHI has either a timeout or a documented alternative, and date each memo so you can show when it was last reviewed.

Identity provider and application configuration exports

Export session lifetime, idle timeout and re-authentication settings from your identity provider and from each application that holds ePHI. Where sign-in is delegated, such as through an OpenID Connect or SAML provider, the provider's session settings usually govern the application session, so capture both. Store exports with timestamps and compare them against the value stated in your risk analysis to catch drift.

Endpoint policy results for screen lock

Workstations and kiosks often rely on operating system screen lock rather than application timeouts. Use endpoint policy checks that report pass or fail per device, and keep the policy definition, the query or assessment that backs it, and the failing device list. Fleet policies, for example, are yes or no questions answered by osquery and show which devices pass or fail each policy. Review failing devices and record the remediation date.

Configuration baseline scan results

Configuration assessment tools compare hosts against benchmark-based policies and flag deviations with remediation advice. Keep the policy version used, the scan date, and the findings for timeout and screen lock checks. Wazuh Security Configuration Assessment uses YAML policies that can be extended with custom checks, so you can add a check that matches your own documented timeout value. Confirm the policy checks what your memo says, not just a generic benchmark.

Test records of enforced timeouts

A configured value is not proof that the session ends. Keep dated test records showing that an idle session on a representative workstation, application and remote path actually terminates after the documented period and requires sign-in again. Record the tester, the test steps and any failures with the fix applied. Repeat tests after identity provider upgrades, application updates and changes to remote access.

Change logs for timeout settings

Every change to a timeout value, identity provider setting or endpoint policy should leave a trace: who changed it, when, why, and which risk analysis entry it affects. Retain these logs alongside your policies and documentation. During an assessment, the change history shows whether the timeout you describe has been stable or quietly altered, and it supports your six-year documentation retention practice.

What meeting automatic logoff costs in money and effort

This table breaks down the cost components of meeting 164.312(a)(2)(iii) across configuration, testing, evidence and assessment, and marks which ones are one-time and which recur. Use it to see who is paid for each part and what to ask for in a quote. No price figures are supplied for this work, so every cost depends on the scope of your environment.

Cost component	One-time or recurring	What drives it up or down
Engineering time to configure timeouts on each system holding ePHI	One-time, then recurring when systems change	Number of applications, EHR and clinical modules, operating systems and endpoint types, and whether session settings are centralized in an identity provider
Testing time to confirm sessions end after the chosen inactivity period	One-time per system, repeated after upgrades	Count of user roles, shared workstation behavior, and whether tests run in a staging environment that mirrors production
Clinical workflow friction review and adjustment	Recurring as workflows change	Clinician complaints about re-login frequency, the number of shared workstations, and emergency access needs that the timeout must not block
Evidence upkeep: written procedure, configuration exports and change records	Recurring	Frequency of system changes, how many systems are in scope, and whether configuration evidence is generated automatically or collected by hand
External review by a consultant or implementation partner	Typically one-time, optional recurring	Scope of the review, the age of the environment, and whether the review covers only the written procedure or also tests live systems
Auditor or assessor sampling of timeout evidence	Recurring with each assessment cycle	Number of systems sampled, quality of existing evidence, and whether the assessor can rely on exported configuration rather than screenshots
Open-source software license spend	Often none for the software itself	License cost is typically removed, but configuration, testing, support and evidence effort still apply in full

Which open-source tools support automatic logoff evidence

Wazuh's Security Configuration Assessment scans monitored endpoints against YAML policies and checks files, directories, registry keys and running processes for misconfigurations. The policies are mostly based on CIS benchmarks and can be extended with custom policies, which is the route to use when your organization sets its own inactivity value. The scan results show which checks passed or failed on each endpoint and recommend remediation, so the output can serve as a dated record that a configured timeout was tested.

Configuration checks: Policies can test whether a screen lock or session timeout setting exists on the endpoint, as long as a matching check is written for the operating system in use.
Custom policies: Where your risk analysis sets a value such as a specific number of minutes, write a policy that reads that exact setting and fails when it differs.
Dated results: Scan history gives an assessor a timeline showing that the setting was checked over time, not only once.
Remediation guidance: Failed checks include recommended fixes, which you should track to closure in your change process.
License: Wazuh is licensed under GPL-2.0-only. Confirm with counsel what that license requires if you modify the software or distribute it outside your organization.

Before you rely on a policy, confirm with the Wazuh documentation which checks ship for your operating systems and test a custom check against a machine set to fail.

Where automatic logoff programs usually fall short

Automatic logoff looks simple on paper, but the rule leaves the timeout to your risk analysis, so gaps usually come from decisions that were never written down or never applied consistently. The cards below cover the gaps assessors most often find and the checks that close them.

Timeout set nowhere in writing

Many organizations configure a timeout on a few systems but never record the value, the owner or the reason in a policy or risk analysis. Under 164.312(a)(2)(iii), the entity must be able to show how the predetermined period of inactivity was chosen. Check that the chosen value appears in your written procedures and that each system's setting traces back to it. An unwritten timeout is treated as no timeout when an assessor asks for evidence.

Inconsistent values across systems

A workstation may lock after a few minutes, the EHR may stay open for hours, and a remote desktop gateway may never time out. Each value may be defensible alone, yet the mix undermines the reasoning in your risk analysis. Build a table listing every system that creates or displays ePHI, its configured timeout, and the layer that enforces it, then reconcile any outlier against the documented decision.

No decision recorded for addressable specification

Automatic logoff is addressable, so the entity must assess whether it is reasonable and appropriate, implement it if so, and otherwise document why and adopt an equivalent alternative measure. Some organizations skip this step entirely. Record the assessment for the specification itself, including the date, the approver and any compensating measure such as screen locking or physical controls. Without that record, the decision cannot be defended.

Sessions surviving browser close or token refresh

Inactivity timers often reset whenever a background request runs, or a refresh token silently extends a session indefinitely. The browser may close while the session stays valid on the server. Test each application by leaving it idle, closing the browser, and checking whether the session still responds. For identity-based sign-in, review refresh token lifetimes in your identity provider, since authentik and FreeIPA settings govern how long a sign-in persists.

Shared workstations bypassing controls

Clinical areas often share workstations, and staff may stay signed in between shifts or use a generic account that is exempt from timeouts. This defeats both the logoff procedure and the unique user identification requirement. Confirm that timeouts apply to shared endpoints, that shift changes end sessions, and that no exemption exists for convenience. Endpoint policy tools can report which devices are passing or failing a check on a given setting.

No re-test after upgrades

Operating system, application and identity platform upgrades can reset timeout settings to vendor defaults or change which component enforces them. A setting that passed last year may silently fail after a patch. Schedule a periodic check of each system's effective timeout after every significant upgrade and record the result. Configuration scanners such as Wazuh Security Configuration Assessment can flag drift on monitored endpoints, but you must confirm which settings your policies actually cover.

Questions buyers ask about automatic logoff

What timeout does HIPAA require for automatic logoff?

The Security Rule does not set a timeout. Section 164.312(a)(2)(iii) requires electronic procedures that end a session after a predetermined time of inactivity, and the covered entity or business associate picks that period. The choice should come from your risk analysis, which looks at where ePHI is viewed, who has access, whether workstations sit in shared or public areas, and how much exposure an unattended session creates. Document the chosen value, the reason for it, and the systems it applies to, so an assessor can trace the number back to the analysis.

Is automatic logoff required or addressable under HIPAA?

It is an addressable implementation specification, not a required one. Under 45 CFR 164.306(d)(3), you must first assess whether automatic logoff is reasonable and appropriate for each system. If it is, you implement it. If it is not, you must document why and adopt an equivalent alternative measure if one is reasonable and appropriate. Addressable does not mean optional. A shared kiosk in a clinic and a laptop used only in a locked office may reach different answers, and both answers need written reasoning.

How much effort does automatic logoff take to implement?

For most environments the work is configuration rather than new software. Effort depends on how many session types exist and how they are managed. Typical cost drivers include the number of endpoints and applications, whether timeouts are set centrally through directory policy or per application, how many EHR, portal and remote access paths must be covered, and how much testing is needed to avoid disrupting clinical workflows such as medication administration. Ask any provider to list each system, its current timeout behavior, and the method used to enforce a new value. Costs for the people doing this work depend on that inventory and the environment, so no general figure applies.

How long does it take to set up automatic logoff?

The duration depends on scope, not on the technical setting itself. A single application with a configurable timeout can be changed quickly, while a mixed estate with legacy clinical systems, shared workstations and several identity sources takes longer because each path needs a decision, a change, a test and a record. Fixed-scope engagements with DeployOpen are agreed in writing before work starts, so the timeline follows from the inventory and the agreed deliverables. Ask for a written schedule that lists systems in order, the testing window for each, and who signs off on the chosen timeout values.

What evidence do we need to show automatic logoff works?

An assessor will look for three things: the documented timeout decision tied to your risk analysis, the configuration that enforces it on each system, and proof that it operates over time. Useful evidence includes policy exports, application configuration screenshots or files, and periodic compliance scan results. Open-source tools can help generate this proof. Wazuh Security Configuration Assessment can check endpoint configurations against YAML policies and report failures with remediation steps. Fleet policies, written as osquery queries, show which devices pass or fail a yes or no check, which can confirm screen lock settings on managed endpoints. Confirm with each vendor which settings their tools can read in your environment before you rely on them.

Can we implement automatic logoff ourselves?

Many organizations can, particularly where a small number of systems and an internal IT team already manage identity and endpoints. The harder parts are usually the inventory, the decision process and the evidence. Teams often miss applications that keep their own sessions, such as browser-based portals, remote access tools or legacy clinical software. Documentation also tends to lag the configuration. Consider outside help for the inventory, for testing against clinical workflows, or for building the evidence set. DeployOpen can plan, implement and document these controls in your own infrastructure under a written scope, but it does not decide your risk tolerance or sign off on compliance, which remain your responsibilities.

Does a certificate prove our automatic logoff complies with HIPAA?

No. HIPAA has no certification, and HHS does not endorse or recognize private certifications. HHS has stated that no Security Rule standard requires an entity to certify compliance, and that a private certification does not prevent HHS from later finding a violation. For automatic logoff, the question an investigator asks is whether your documented decision was reasonable, whether it was implemented, and whether it stayed in place. A third-party assessment can test those points and report findings, but it does not create a HIPAA certificate. Ask any assessor to state exactly what their report covers and what it does not.

How DeployOpen configures and evidences automatic logoff

DeployOpen starts by agreeing in writing which systems, sessions and user populations fall inside the automatic logoff scope. In a self-hosted environment that usually means the ePHI applications, the operating system sessions of workstations and servers that reach them, and any administrative consoles, with the list tied to the systems the client's risk analysis already identifies. The organization owns the timeout decision itself: the rule does not set a number, so the client's security official and risk owners choose the inactivity period for each session type and record the reasoning. DeployOpen does not choose that value on the client's behalf, and it does not issue audit reports or attestations. Scope, deliverables and timelines are agreed in writing before any work starts.

Once the timeout is decided, DeployOpen configures the supporting tooling inside the client's own infrastructure. Where applications support it, sign-in is delegated to an identity provider such as authentik (MIT), which supports OAuth2 and OpenID Connect, SAML, LDAP, RADIUS and proxy providers, so session lifetimes are set in one place rather than per application. For endpoints, Fleet (MIT) can run osquery-based policies that ask yes or no questions of devices, such as whether a screen lock with the agreed timeout is enabled, and its policies page shows which devices pass or fail. Wazuh (GPL-2.0-only) Security Configuration Assessment can check the matching configuration files and processes on monitored hosts against YAML policies, including custom ones written for the client's chosen value. Whether each product enforces a given setting on a given platform must be confirmed against that product's documentation and tested in the client's environment before it is relied on.

DeployOpen then tests enforcement rather than assuming it. Test cases typically include leaving a session idle past the threshold, confirming the session ends or locks and that re-authentication is required, and checking that the failing state appears in Fleet or Wazuh when a device is misconfigured. The resulting evidence package usually holds the written timeout decision and its risk analysis link, the exported configuration, policy results over time, and test records with dates and the people who ran them. Assessors will decide whether that evidence is sufficient, and the client should ask its auditor early which format they expect. Because automatic logoff is addressable, the record should also show that the decision was assessed and, if a timeout was not adopted, why and what equivalent measure was used.

164.312(a)(2)(iii) Automatic logoff