164.308(a)(5)(ii)(C) Log-in monitoring: requirements and evidence

What 164.308(a)(5)(ii)(C) log-in monitoring requires of your systems

The rule calls for procedures to monitor log-in attempts and report discrepancies, such as repeated failed log-ins. It is an addressable specification, so the covered entity or business associate must first assess whether it is reasonable and appropriate for its environment. If it is, the entity implements it. If it is not, the entity documents why and implements an equivalent alternative measure, if one is reasonable and appropriate, as described in 45 CFR 164.306. Addressable does not mean optional. Skipping the specification without a documented assessment and alternative is a gap an assessor will raise. The risk it addresses is familiar: credential guessing against exposed portals, reuse of passwords stolen from other breaches, and insider misuse by someone who keeps trying access to records outside their role. Monitoring is the detective control that shows these attacks are happening before an account is compromised. The work is harder than it looks because log-in events are spread across many systems: the EHR, directory services, VPN concentrators, email, remote access tools, cloud consoles and any self-hosted application that holds ePHI. Each one records authentication differently. The practical decisions are which systems are in scope (the risk analysis should drive this), what counts as a discrepancy (for example, a set number of failures from one account or source within a window), who receives the alert, and who is accountable for acting on it. Without defined thresholds and named owners, the monitoring exists on paper but produces no decisions. Confirm these thresholds with your security official and record them in the policy. This specification is narrower than the information system activity review in 164.308(a)(1)(ii)(D), which covers regular review of system activity records broadly, including access reports and incident tracking. Log-in monitoring targets authentication events specifically, and it often runs continuously with automated alerts, while activity review is a scheduled human review. Both produce evidence an assessor will ask for. Also note that there is no HIPAA certification for log-in monitoring or for any other Security Rule safeguard. HHS does not recognize private certifications, so the evidence you keep is the configuration, the alert records and the documented decisions behind them.

Which systems, accounts and vendors fall under log-in monitoring

Log-in monitoring under 164.308(a)(5)(ii)(C) applies wherever a login can reach ePHI, including accounts that bypass normal user sign-in. Start with an inventory of authentication points, then let the risk analysis decide which of them need the tightest monitoring and alerting.

Every system that authenticates to ePHI

Inventory each login point that can reach ePHI, including the EHR, file shares, VPN concentrators, remote desktop gateways, admin consoles, cloud consoles and both self-hosted and SaaS applications. A system left off this list is a system whose failed log-ins nobody reviews. Record the authentication source for each one, such as a local directory, a central identity provider or a vendor-managed login, because that determines where the events are logged.

Privileged and administrative accounts

Administrator, database owner and break-glass accounts deserve the closest attention because they can change access rules and disable controls. Confirm that failed and successful sign-ins for these accounts are logged, that alerts reach a named person, and that emergency accounts are not used for routine work. Privileged activity is often the first sign of an intrusion, so these events should not sit in a log nobody reads.

Service and integration accounts

Service accounts that connect interfaces, backups, reporting tools and scheduled jobs often use static credentials that never trigger a password prompt. Failed authentications from these accounts can signal a stolen or misconfigured secret, so they need monitoring even though no person signs in. Ask each system owner which service accounts exist, who holds their credentials and where their authentication events are recorded.

Workforce logins versus patient portal logins

Workforce log-ins to systems holding ePHI are the core scope for this specification. Patient portal and consumer-facing log-ins also touch ePHI, so the risk analysis should decide whether repeated failures there need the same reporting path, credential stuffing being a common pattern. Keep the two populations separate in your reports so that a spike in patient failures does not hide a workforce compromise.

Vendors that host ePHI for you

When a vendor hosts or processes ePHI for you, it is a business associate, and its login events may be the only record of who accessed your data. Your business associate agreement and vendor due diligence should confirm which failed log-in events the vendor records, how long it keeps them, and how it notifies you of discrepancies. Where the vendor cannot share these events, document the gap and the compensating measure.

Thresholds set by the risk analysis

The risk analysis under 164.308(a)(1)(ii)(A) should rank systems by the sensitivity of the ePHI they expose and how exposed their log-in paths are, such as internet-facing VPN or portal access. Those rankings set which systems get automated lockout or alerting thresholds, how quickly reviewers respond and how often logs are reviewed. Document the thresholds and the reasons for them, since the rule leaves the specific numbers to the entity.

How an assessor tests log-in monitoring

This table lists what an assessor checks for 164.308(a)(5)(ii)(C), the evidence requested for each check, and the gaps assessors most often record. Read it as a pre-assessment checklist: each row is a question the assessor will ask, so confirm you can answer it with dated, retrievable records before the review starts.

Test area	What the assessor checks	Evidence requested	Common finding
Addressability decision	Whether the entity assessed if log-in monitoring procedures are reasonable and appropriate, and recorded the outcome	Signed risk analysis entry or addressability memo with the decision, rationale and date	No documented decision on addressability, so the specification is treated as not addressed
Alternative measure	If the procedure was judged not reasonable and appropriate, whether a documented equivalent measure exists	Written rationale and the alternative control, with evidence it operates	Entity declares a gap but cites no equivalent measure
Failed log-in capture	Whether failed authentication events are generated and collected from in-scope systems	Sample of failed log-in events from directory, application and remote access sources, with timestamps and user identifiers	Some ePHI systems, such as legacy applications or admin consoles, do not record failed attempts
Log retention	Whether authentication logs are kept long enough to support review and investigation	Retention settings and a restore or query showing older log-in records are still available	Logs overwritten on a short cycle or stored only on the originating host
Thresholds and alert rules	Whether defined thresholds, such as repeated failed attempts, trigger alerts and whether rules match the risk analysis	Rule configuration exports, threshold rationale and test alerts fired during a sampled period	Rules exist but thresholds are never reviewed or were set without reference to identified risks
Alert recipients	Who receives alerts and whether they are able to act on them	Distribution lists, on-call rota, alert routing configuration and acknowledgment records	Alerts sent to a mailbox or channel no one monitors, or to a former employee
Discrepancy reporting	Whether discrepancies found in log-in reviews are reported to the security official and resolved	Sampled tickets showing detection, escalation, investigation outcome and closure	Reviews performed but findings not recorded, or tickets left open without resolution
Review cadence	Whether reviews of log-in activity happen on a defined schedule and are documented	Review logs or sign-offs for sampled periods, with reviewer name and findings	Monitoring tool in place but no evidence any person reviewed its output

How to implement log-in monitoring step by step

This sequence turns the addressable log-in monitoring specification into a documented, tested control. It starts from the risk analysis, ends with evidence that alerts reach a named owner, and leaves a record of each decision along the way.

Inventory every authentication source
List each system where workforce members or service accounts log in to reach ePHI, including the directory service, the EHR, remote access gateways, email, file shares and any self-hosted applications. Pull this list from the risk analysis and the ePHI location map so that nothing holding ePHI is left out. The step is complete when the inventory names each source, its owner and whether it writes authentication events to a log you can read. Keep the inventory with the risk analysis records so an assessor can trace the scope back to it.
Decide and document the addressable determination
Under 45 CFR 164.306(d)(3), the security official assesses whether log-in monitoring is reasonable and appropriate for each source, given the risk analysis. If it is, document the decision and the procedure. If it is not, write down why and record the equivalent alternative measure you adopt, if one is reasonable and appropriate. The output is a signed or approved determination for each source, dated and stored with your policies, so the reasoning is visible to an auditor.
Define monitoring criteria and thresholds
Set the events you will watch and the conditions that count as a discrepancy. Typical criteria include repeated failed log-ins for one account, failures from many accounts originating at one address, log-ins outside expected hours or locations, and account lockout events. Choose the thresholds from your risk analysis and your own environment rather than from a template, and confirm with each application vendor which authentication events it actually records. The output is a written criteria table that links each rule to the source it applies to.
Centralize authentication logs
Forward authentication events from every source in the inventory to one location where they can be searched, retained and correlated. Self-hosted options such as Wazuh can decode collected logs and compare events against built-in and custom rules, and OpenSearch Security Analytics can match ingested logs against Sigma rules. Confirm each platform's current capabilities before relying on them, and verify that the sources are sending timestamps and user identifiers in a consistent format. You know the step is done when a test log-in from each source appears in the central store within the time your procedure requires.
Route alerts to a named owner
Configure the rules so matching events create alerts, and send those alerts to a named owner who can act on them. The owner should be a role, backed by a named individual and a deputy, and the channel should be one that is monitored outside working hours if your risk analysis calls for it. Write a response procedure that tells the owner how to triage a failed log-in pattern, when to lock or review an account, when to escalate to the incident response process, and how to record the outcome. The output is the routing configuration, the on-call record and the approved procedure.
Test with simulated failed log-ins
Run controlled failed log-in attempts against a test account on each source, then confirm that the events are logged, the rule fires and the alert reaches the named owner. Repeat the test after any change to the source, the rule set or the routing. Record the test date, the accounts used, the expected result, the actual result and any gaps found. If a source does not produce a detectable event, document the gap and the compensating measure, and treat it as a finding for the risk management plan. Use a test account that cannot reach ePHI, and agree the test window with the people who run each system.
Record the output of each step
Keep a single evidence file that links each step to its artifact: the source inventory, the addressable determination, the criteria table, the log forwarding configuration, the alert routing record, the response procedure and the test results. Review the file when the risk analysis is updated or a new authentication source is added, and record each review. The step is complete when an assessor could follow the chain from the risk analysis to a test result without asking for additional explanation. Confirm with your auditor or counsel how long these records must be retained under your policies.

How open-source logging stacks produce log-in evidence

An open-source logging stack produces log-in evidence only for the systems you configure to record authentication events. Each tool below captures something different, so the first decision is which systems hold ePHI and which of their log-in paths must be recorded. For each one, confirm in its own configuration that failed and successful authentication attempts are written to a location you control and retained long enough for review. Nothing in these products turns on log-in monitoring by default for your environment.

Nextcloud's admin_audit app writes additional event information to audit.log in the data directory, or to a path set with logfile_audit. Confirm that the app is enabled, that the log path sits on storage with restricted permissions, and that authentication-related events appear in a test log-in. OpenBao audit devices keep a detailed JSON log of every API request and response, including errors, with most sensitive values hashed with HMAC-SHA256. That makes failed token and policy checks visible, but the audit device must be enabled before the events occur, and you should confirm that the hashing meets your reviewers' needs for investigating a specific credential.

Wazuh decodes collected logs and compares each event against a ruleset of over 3,000 built-in rules and decoders plus custom rules, writing matches to alerts.log and alerts.json and forwarding them to the Wazuh indexer. OpenSearch Security Analytics runs detectors against ingested logs using prepackaged or custom Sigma rules, records findings, and can send alerts to Slack or email. Neither tool knows your authentication sources until you ingest them, and the built-in rules cover only the log types you collect. Document which rules flag repeated failed log-ins, who receives those alerts, and how each alert is closed out, because that record is what shows discrepancies were reported.

Evidence that satisfies log-in monitoring and how to keep it current

An assessor will look for a decision on the addressable specification, logs that show authentication events, rules that define what counts as a discrepancy, and records that someone reviewed and acted on them. The cards below cover each artifact and the routine that keeps it accurate between reviews.

Addressability decision memo

Under 164.306(d)(3), the organization must record whether log-in monitoring is reasonable and appropriate given its risk analysis. The memo names the decision, the ePHI systems in scope, the factors weighed and the owner who signed it. If the answer is no, it must document why and the equivalent alternative measure. Check that the memo references the current risk analysis and carries a review date. A memo that predates a major system change is a common gap.

Authentication log samples

Export samples of successful and failed log-in events from each in-scope system, with timestamps, user IDs, source addresses and outcome fields. Assessors check that the timestamps are synchronized and that the user IDs can be traced to a named workforce member. Confirm that the samples cover identity providers, directories, remote access gateways and applications that store ePHI, not only the most visible system.

Alert rules and thresholds

Document the conditions that generate a discrepancy report, such as a set number of failed log-ins within a window, log-ins from unusual locations, or repeated lockouts on privileged accounts. Record the threshold values, who approved them and how they were chosen from the risk analysis. Keep the rule export with its version history so an assessor can see what was active on any given date.

Alert records and review tickets

Show that alerts were triaged and that discrepancies were reported. Each record should carry the alert time, the affected account, the reviewer, the disposition and any escalation. Tickets linked to a security incident or to a password reset are strong evidence. Confirm that reviews happen at a set frequency and that closed tickets show the reasoning, not only a status change.

Rule change and access records

Every change to a detection rule, threshold or log source is a change to the control. Keep approval records and access logs showing who could edit the rules and who did. Review the list of administrators who can change log-in monitoring configuration at least as often as general user access. Missing change records make the rest of the evidence harder to rely on.

Simulated failed log-in tests

Run controlled tests that produce repeated failed log-ins against a test account and confirm that the rule fires, the alert reaches the reviewer and the ticket is created. Record the date, the test script, the expected result and the actual result. Repeat tests after any change to the identity provider, rule set or logging pipeline. Use a non-production account so that the test does not lock out real users.

What log-in monitoring costs in money and effort

This table breaks down the cost components of meeting the log-in monitoring addressable specification, showing who is paid for each, whether it is one-time or recurring, and what drives it up. Use it to build a quote request and to separate software spend, which is often low for open-source tools, from the staff and evidence work that usually dominates.

Cost component	Who is paid, and for what	One-time or recurring, and main drivers
Tooling and licenses	No license fee for the Apache-2.0, GPL-2.0-only and MPL-2.0 tools named in the topic. Confirm any paid support or subscription options with each vendor.	Licenses are zero, but hosting and storage are recurring. Log volume, retention period and number of monitored sources drive them.
Infrastructure hosting and log storage	Cloud provider or data center operator for compute, disks and backups of the log pipeline.	Recurring. Event volume per day, retention length and index replication settings are the main drivers.
Engineering time to configure sources	Internal platform team or implementation partner for enabling authentication logging in each system.	One-time for initial setup, then recurring when new applications or identity providers are onboarded.
Detection rule authoring and tuning	Security engineers or a partner who write, test and tune rules for repeated failed log-ins and other discrepancies.	Initial build is one-time. Tuning recurs to reduce false positives and to match changes in the risk analysis.
Alert triage staffing	Internal security operations staff, a managed service, or a contracted analyst who reviews and closes log-in alerts.	Recurring and usually the largest ongoing cost. Alert volume, on-call coverage and documented escalation paths drive it.
Evidence upkeep	Compliance lead or security official who keeps review records, sampled alerts and documented discrepancy decisions current.	Recurring. Review frequency set by the entity's own policy and the number of systems in scope drive the effort.
Policy and procedure documentation	Security official or consultant who writes the log-in monitoring procedure and the criteria for what counts as a discrepancy.	One-time drafting, then recurring review when systems or threats change. Confirm the review cycle in your own policy.
External testing or review	Independent penetration tester or assessor who checks whether failed log-ins are detected and reported.	Periodic. Scope, number of applications and whether testing is repeated drive the fee. Ask for a written scope.
Auditor sampling and examination	Independent auditor or assessor who samples log-in monitoring records and review evidence during an examination.	Recurring per examination cycle. Number of systems sampled and quality of retained evidence drive the effort.

Who owns log-in monitoring, who can help, and where the auditor stops

Your organization owns this addressable specification. The Security Rule places the duty on the covered entity or business associate, so the decision about whether log-in monitoring is reasonable and appropriate, how it is scoped and what happens when it fires belongs to your team. Vendors can build the pipeline, but they cannot accept the risk on your behalf.

The addressable decision: Record whether log-in monitoring is reasonable and appropriate for each system holding ePHI, based on your risk analysis. If you decide an alternative measure is better, document the reasoning and the measure.
Thresholds and rules: Set which failed log-in patterns count as a discrepancy, who receives each alert and how quickly it must be reviewed.
Alert response: Staff must investigate, escalate and close each alert, and link confirmed events to the incident response procedure.
Sign-off and review: A named security official or delegate approves the monitoring design and reviews it after environment changes.
Workforce training: Staff must know how to report suspicious log-in activity, which feeds the broader security awareness program.

Before any outside work begins, confirm in writing which of these decisions you will keep in house.

Common gaps in log-in monitoring and how to close them

Most organizations under 164.308(a)(5)(ii)(C) already collect authentication events, so the gaps are rarely about logging alone. They sit in the decisions around the logs: whether the specification was assessed, who reviews the output, what counts as a discrepancy, and whether the arrangement still works after people and systems change.

No documented addressability decision

Because this is an addressable specification, the file must show that the entity assessed whether log-in monitoring is reasonable and appropriate for its ePHI systems. Many organizations implement monitoring without recording that assessment, or they record a decision to skip it with no equivalent measure. Check that the risk analysis references this specification and that the reasoning is dated and signed off by the security official.

Failed log-ins logged but never reviewed

Authentication events are often written to a log store that nobody opens until an incident. The specification asks for procedures to monitor log-in attempts and report discrepancies, so monitoring means a named person or automated alert looks at failures on a set schedule. Ask who reviews the failed log-in report, how often, and where each review is recorded.

No thresholds for repeated failures

Without defined thresholds, staff cannot tell a mistyped password from a password-guessing attack. Procedures should state how many failed attempts in what window count as a discrepancy, which accounts are watched more closely (administrators, remote access), and what happens next. Thresholds should come from the risk analysis, and the procedure should show the values in use.

Logs missing for SaaS and vendor-hosted systems

Log-in events for email, collaboration tools and vendor portals often never reach the central log store, so failed attempts against those systems go unseen. Inventory every system that holds or grants access to ePHI, confirm which ones produce authentication logs, and document where vendor-hosted logs are kept and how long they are retained. Business associate terms should cover log access.

Alerts unrouted after staff turnover

Alerts often go to a distribution list or an individual mailbox that no longer belongs to an active employee. When the security official or an administrator leaves, failed log-in alerts can silently stop reaching anyone. Review alert recipients at each workforce change, tie routing to roles rather than names, and test that an alert reaches a live recipient.

No proof of testing

A monitoring rule that has never fired is unproven. Organizations should test that a simulated run of failed log-ins produces a log entry, a finding and a notification, then keep the test record. Retain the test date, the scenario, the result and any fixes. Ask an independent assessor which evidence they would expect to see before the next review.

Questions buyers ask about log-in monitoring

Is log-in monitoring required under the HIPAA Security Rule or is it optional?

Log-in monitoring is an addressable implementation specification, not a required one, so you must still decide deliberately how to handle it. Under 45 CFR 164.306(d)(3), you assess whether procedures for monitoring log-in attempts and reporting discrepancies are reasonable and appropriate for your environment. If they are, you implement them. If they are not, you document why and implement an equivalent alternative measure where that is reasonable and appropriate. Skipping the specification with no written assessment is the outcome to avoid, because the assessment itself is what an auditor will ask to see. Your risk analysis is the natural place to record the reasoning.

How much effort does HIPAA log-in monitoring take, and what drives it?

Effort depends mostly on how many systems hold ePHI, how many users authenticate to them, and how much alerting you want. The one-time work includes inventorying log-in sources, deciding thresholds for repeated failed log-ins, writing the procedure, and wiring alerts to a person who acts on them. The recurring work is reviewing reports, investigating discrepancies, and tuning rules as staff and systems change. Smaller environments with few systems can often cover this with a short written procedure and a periodic review. Larger environments with many identity sources usually need central log collection. Ask any consultant or vendor to break their estimate into setup and ongoing review so you can see which part scales with your footprint.

Can self-hosted open-source tools meet the log-in monitoring specification?

Self-hosted open-source tools can produce much of the evidence this specification asks for, but they do not make the decision for you. Nextcloud's admin_audit app writes additional event information to an audit log file, OpenBao keeps a detailed JSON log of every API request and response, and Wazuh compares collected events against a ruleset of over 3,000 built-in rules and decoders and writes matching alerts to alerts.log and alerts.json. OpenSearch Security Analytics can run detectors against ingested logs and send alerts to channels such as email. Whether any of these detects the failed log-in patterns in your environment depends on which log sources you feed them and how you configure rules. Confirm each product's authentication event coverage in your own deployment before relying on it.

Do we need a consultant to set up HIPAA log-in monitoring?

You do not legally need a consultant, but many organizations bring in help for the technical setup or the written assessment. Your organization owns the decision, the procedure, and the workforce that responds to alerts. An implementation partner such as DeployOpen can configure logging, deploy collection and alerting inside your own infrastructure, and document the evidence, under a fixed scope agreed in writing. It cannot decide whether the specification is reasonable for you, and it does not issue audit reports or attestations. Independent assessors test what you show them. If you use outside help, ask for a written scope listing log sources, alert rules, and the documents handed over.

What will an auditor sample when checking log-in monitoring?

An auditor typically asks for the documented procedure, the risk analysis entry showing how you reached your decision, and proof the procedure runs. Expect requests for a sample of log-in monitoring reports or alerts across a period, evidence of how discrepancies were reviewed and who closed them, and the configuration showing which systems are covered. If you chose an alternative measure, the written rationale and the alternative's own evidence will be sampled too. The HHS OCR audit program reviews compliance with Security Rule provisions, so keep records that show the monitoring was operating, not only that it was planned.

How does log-in monitoring differ from information system activity review?

Log-in monitoring targets authentication events, such as repeated failed log-ins and discrepancies in who is signing in. Information system activity review under 164.308(a)(1)(ii)(D) is broader: a required, regular review of system activity records such as audit logs, access reports, and security incident tracking. Log-in events are one input to that review. Monitoring is the specific procedure that watches authentication, while activity review is the recurring management process that examines all relevant records. Keeping the two distinct in your documentation helps an assessor see that each has an owner and a schedule.

What should we confirm before writing the log-in monitoring procedure?

Confirm which systems hold ePHI and which of them authenticate users locally or through a central identity provider. Confirm that each one actually writes authentication events, and where those events are stored and for how long. Decide what counts as a discrepancy, such as a set number of failed attempts within a window, and who receives the alert. Check the current NIST SP 800-66 Rev. 2 guidance, which groups log-in monitoring with malicious software protection and password management, and review the HHS Security Rule materials for context. Then test the procedure with a real failed log-in and confirm the alert reaches the right person.

Where to read the rule and the NIST guidance

Start with the regulation itself. The text of 45 CFR 164.308(a)(5)(ii)(C) is short: it asks for procedures for monitoring log-in attempts and reporting discrepancies, and it is an addressable specification. Read it alongside 45 CFR 164.306, which sets the general rules for addressable specifications. Section 164.306(d)(3) is where the decision lives: you must assess whether monitoring log-in attempts is reasonable and appropriate for your environment, document the outcome, and, if you decline it, record why and adopt an equivalent alternative that is reasonable and appropriate. Confirm the current eCFR text before you cite it in a policy, because the eCFR is the authoritative version and the proposed revision discussed elsewhere on this page would change the Security Rule.

Next, read NIST SP 800-66 Rev. 2, the February 2024 resource guide. It does not treat log-in monitoring as a standalone topic. Section 5.1.5 places it inside the security awareness and training standard, grouped with protection from malicious software and password management. Use that grouping to decide ownership: the people who write the training program, the team that tunes authentication alerts, and the owner of password policy should meet before the log-in monitoring procedure is drafted. The guide's key activities and sample questions give you a checklist for what an assessor is likely to ask. HHS lists the guide as informational, so it helps you evidence your reasoning but does not replace the regulation or your own risk analysis.

Before you rely on either source, confirm two things with your compliance lead or outside counsel: which version of the eCFR text is current on the day you finalize your procedure, and whether your organization is also bound by any state law or contract that sets its own log-in monitoring expectations. Keep the regulation, the guide and your documented decision together in one location so that the procedure can be traced back to its source during an OCR inquiry.

164.308(a)(5)(ii)(C) Log-in monitoring