HIPAA Evidence from Azure AD Sign-In Logs
Why this matters for HIPAA
Any system that authenticates users to access electronic protected health information (ePHI) falls under the HIPAA Security Rule’s person/entity authentication requirement. If Azure AD / Entra ID is the identity provider in front of those systems, its sign-in logs are the primary evidence that authentication controls actually work — and, just as importantly, that anomalies were detected and investigated, since HIPAA breach notification timelines start from when a breach is discovered, not when it happened.
What evidence Azure AD sign-in logs provide
- Proof of person/entity authentication enforcement for accounts with access to ePHI-handling systems (§164.312(d))
- A defensible timeline of when an authentication anomaly was first visible in the logs, which matters directly for §164.308(a)(6) (Security Incident Procedures) breach-notification timing
- Evidence of MFA enforcement specifically for accounts with elevated access to clinical or billing systems
- A record of conditional access policy decisions that can demonstrate access was risk-conditioned, not just password-gated
How LogTriage maps this to HIPAA
Authentication-attack detections (credential stuffing, impossible travel, MFA bypass) are mapped to §164.312(d) (Person/Entity Authentication), and any high-severity or critical finding is additionally mapped to §164.308(a)(6), with a remediation note specifically flagging the breach risk assessment timeline HIPAA requires once a security incident is confirmed.
Evidence checklist
- Identify every account with sign-in access to a system that stores or transmits ePHI
- Confirm MFA is enforced for all such accounts, with no legacy-protocol bypass paths
- Retain sign-in logs covering at least your organization’s defined incident look-back window
- Document the exact timestamp an anomaly was first detectable in the logs versus when it was actually investigated — this gap is what breach-notification timelines are measured against
- Maintain a documented security incident response procedure that references log-based detection as a discovery trigger
Frequently Asked Questions
- Does HIPAA require sign-in log monitoring for covered entities?
- Yes. The HIPAA Security Rule's Technical Safeguard provisions (45 CFR 164.312) include Audit Controls requiring covered entities to implement mechanisms to record and examine activity in information systems containing ePHI. Sign-in logs for systems that access ePHI directly satisfy this requirement.
- What makes an Azure AD sign-in relevant to HIPAA versus irrelevant?
- Scope. If the Azure AD tenant is used to authenticate access to systems that store or process electronic protected health information (ePHI), the sign-in logs are in scope. An Azure AD tenant used only for non-healthcare SaaS tools with no ePHI contact is out of scope, though boundary analysis should be documented.
- How long must HIPAA audit logs be retained?
- HIPAA requires retaining documentation of security policies and procedures for six years from creation or last effective date. For specific system access logs, the standard is typically interpreted as six years, though state law may impose longer requirements.
- Does LogTriage's compliance mapping cover HIPAA's specific Safeguard categories?
- Yes. LogTriage maps to HIPAA Technical Safeguard requirements including Audit Controls, Access Control, and Person or Entity Authentication. The specific control reference appears in every report alongside the detected finding, making the connection between a security event and its compliance relevance explicit.
Related Resources
See your compliance mapping generated automatically
Every LogTriage report includes a deterministic compliance mapping — SOC 2, PCI DSS, HIPAA, NIST CSF, and ISO 27001 — stamped on every report, AI-generated or rule-based.