azcomputerguru/claudetools
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity
Files
0a0054c9caeaa12a840745be56105d0d91bf0749
claudetools/clients/cascades-tucson/docs/security/hipaa-caregiver-controls.md
Howard Enos 0a0054c9ca sync: auto-sync from HOWARD-HOME at 2026-05-11 18:06:36 
Author: Howard Enos
Machine: HOWARD-HOME
Timestamp: 2026-05-11 18:06:36
2026-05-11 18:06:39 -07:00

20 KiB
Raw Blame History

Cascades — Caregiver shared-phone access: HIPAA compensating-controls architecture

Owner: Howard Enos (howard@azcomputerguru.com) Status: Live in production for pilot user pilot.test@cascadestucson.com as of 2026-05-11. Staged caregiver rollout pending pilot SSO verification. Last updated: 2026-05-11 Review cadence: Annual minimum, plus event-driven (any incident, any change to caregiver auth flow, any major M365/Intune licensing change)

Purpose

This document records, in writing as required by HIPAA Security Rule §164.316(b)(1) (Documentation), the design decision and compensating-controls architecture for caregiver access to ALIS (EHR) and Microsoft 365 services from the shared Cascades caregiver phones.

The relevant rule sections being addressed:

  • §164.312(a)(1) — Access Control (standard, required)
  • §164.312(a)(2)(i) — Unique user identification (required implementation specification)
  • §164.312(a)(2)(iii) — Automatic logoff (addressable)
  • §164.312(b) — Audit controls (standard, required)
  • §164.312(d) — Person or entity authentication (standard, required)
  • §164.308(a)(1)(ii)(B) — Risk Management (required)
  • §164.306(b) — Flexibility of approach (the basis on which compensating controls are accepted)

Scope

This architecture applies only to the caregiver shared-phone access path. Other access paths (workstation sign-ins, off-network access for office staff, admin accounts) are governed by separate policies (the standard tenant CA suite, including the legacy "Require MFA for all users" and the Microsoft-managed admin MFA policies).

In scope:

  • Phones in Intune device group Cascades - Shared Phones (id ea96f4b7-3000-45da-ab1f-ddb28f509526)
  • Users in Entra security group SG-Caregivers-Pilot (id 0674f0bc-6ff4-49c7-802d-2abf591ba371) — currently pilot.test@cascadestucson.com only; will expand to live caregivers per the staged rollout plan in docs/cloud/caregiver-m365-p2-rollout.md.

Design decision

MFA is not used as an authentication factor for caregivers in the shared-phone access path. Person authentication (§164.312(d)) is satisfied by password against Entra ID combined with a strict multi-layer environmental gate (network + device + session) that compensates for the absence of MFA.

Why MFA is operationally infeasible here

  1. Shared phones have no per-caregiver phone number, SIM, or personal Authenticator app. The phones are work-only handsets in Microsoft Entra Shared Device Mode; caregivers sign in at the start of a shift and sign out at the end, so the same physical device is used by many caregivers across shifts.
  2. Personal phones are not provided to and not relied on as a corporate MFA factor for caregivers. The caregiver staff population is high-turnover hourly labor; mandating a personal-device MFA enrollment as a condition of employment is operationally untenable.
  3. FIDO2 security keys per caregiver are cost-prohibitive at scale and add a physical-token-management burden that does not survive Cascades' employee turnover rate.

Why compensating controls are an acceptable alternative under HIPAA

HIPAA Security Rule does not mandate MFA. It requires "reasonable and appropriate" safeguards (§164.306(b)) given the covered entity's size, complexity, capabilities, infrastructure, and risk environment. NIST SP 800-66r2 and the 2024 HHS Cybersecurity Performance Goals recommend MFA as best practice, but neither is binding rule text. The Office for Civil Rights (OCR) evaluates implementations against "reasonable and appropriate" rather than a specific control checklist.

Cascades is a small (~25 employee) assisted living facility. The cost and operational burden of per-caregiver MFA exceeds the marginal risk reduction it would provide over the compensating controls described below.

Compensating controls

The risk that MFA normally mitigates — credential reuse, credential theft, phishing-driven account takeover — is mitigated here by four independent, layered controls. Each is independently enforceable and independently auditable.

Layer 1: Network restriction — only sign in from Cascades

CA policy: CSC - Block caregivers off Cascades network Policy ID: e35614e1-e896-4a13-9407-076963af488f State: Enabled Logic: All sign-ins by members of SG-Caregivers-Pilot from any location other than the named location Cascades are blocked. The Cascades named location is defined as the public IPs 72.211.21.217/32 and 184.191.143.62/32 (id 061c6b06-b980-40de-bff9-6a50a4071f6f, isTrusted: true).

Risk reduction: A stolen credential cannot be used from a remote location. The attacker must be on the Cascades public IP — i.e., physically connected to Cascades' network or behind its NAT.

Layer 2: Device restriction — only sign in from a managed compliant phone

CA policy: CSC - Block caregivers on non-compliant device Policy ID: ede985e2-ee7e-4521-88b2-34c847c3db20 State: Enabled as of 2026-05-11T18:06:21Z (previously Report-only — flipped during pilot SSO build-out). Logic: All sign-ins by members of SG-Caregivers-Pilot from a device that is not Intune-marked compliant are blocked. Compliance is governed by Intune compliance policy CSC - Android Compliance (id 27eeaeda-8390-462e-a514-7d2a558f412c), which requires the device be:

  • Enrolled in Intune as androidEnterpriseDedicatedDevice with joinType: azureADRegistered
  • Member of the dedicated phone device group (Cascades - Shared Phones)
  • Encrypted, locked, with passcode, OS patch level current
  • Running the Shared Device Mode profile (profileType: Shared)

Risk reduction: A stolen credential cannot be used from a personal phone joined to cscnet Wi-Fi, from a guest laptop, from a kiosk PC, or from any other device that is not the corporate-managed and Intune-attested phone. Combined with Layer 1, the attacker must be physically on Cascades' network and in possession of a Cascades corporate phone.

This is the load-bearing control of the architecture. It is the substitute for MFA. Both Layer 1 and Layer 2 must remain Enabled at all times for the architecture to be HIPAA-defensible.

Layer 3: Session restriction — auto-logoff and re-auth cadence

CA policy: CSC - Caregiver sign-in frequency 8h Policy ID: 7d491c7a-ad90-4420-9990-40a1e676a76c State: Enabled Logic: Session sign-in frequency enforced at 8 hours for SG-Caregivers-Pilot. After 8 hours, all session tokens must be re-issued by re-authentication.

Plus, on the device itself:

  • Managed Home Screen configured with kioskModeManagedHomeScreenAutoSignout: true (in CSC - Android Shared Phones Restrictions, id 070a76c2-a8c3-4f7f-9ba7-1f4ac5084184) — when one caregiver taps "Sign out" all M365 sessions clear device-wide.
  • Shared Device Mode itself ensures M365 apps share a single sign-in state per device — no cross-caregiver token leakage.

Risk reduction: Even if a sign-in slips past Layers 1+2 (e.g. legitimate-but-careless caregiver sign-in left active on the phone), the session expires automatically. Implements §164.312(a)(2)(iii) (automatic logoff).

Layer 4: Identity Protection risk-based de-facto block

CA policies (unchanged from tenant defaults):

  • Require MFA when risky sign-ins are detected (id 76f1dd72-4003-4984-bb4a-6fcead072c2c)
  • Require MFA and password change when high-risk users are detected (id 9f123001-a95f-4e50-9860-4dd2254cccad)

Both targets All Users. Caregivers are NOT excluded.

Logic: When Microsoft Identity Protection evaluates a caregiver sign-in as signInRiskLevel: medium+ or userRiskLevel: high, the CA policy challenges for MFA. Caregivers have no MFA method registered (by design — see "Why MFA is operationally infeasible"). The MFA challenge cannot be satisfied. The sign-in fails.

Risk reduction: Microsoft's risk engine remains active for caregivers. Unusual sign-in patterns (impossible travel, anonymous IP, leaked-credential detection, unfamiliar properties) result in failed sign-ins, not weakly-authenticated sign-ins. The "no MFA registered → cannot satisfy challenge → blocked" path is the equivalent of an explicit risk-based block clone (which would be the architecturally cleaner solution but requires Entra ID P2 licensing Cascades does not currently have — see "Notes" below).

Layer 5 (implicit): Unique user identification + audit

§164.312(a)(2)(i): Each caregiver has a unique UPN in Entra (firstname.lastname@cascadestucson.com). No shared accounts. Phones are shared; identities are not. Each sign-in event is attributable to one specific human caregiver.

§164.312(b): Every caregiver sign-in is recorded in Entra sign-in logs with: timestamp, user UPN, app, IP, device ID, conditional access evaluation result, applied policies, and authentication method. Retention is governed by the ACG-side audit retention pipeline (see .claude/skills/remediation-tool/references/audit-retention-runbook.md). Sign-in logs are reviewable for incident response and audit.

Authentication Methods Registration Campaign exclusion

To prevent caregivers being interrupted by the "register Authenticator now" sign-in nudge — which would offer a method they have no operational way to use and would confuse the caregiver UX — SG-Caregivers-Pilot is excluded from the tenant Authentication Methods Registration Campaign:

Object: /policies/authenticationMethodsPolicy → registrationEnforcement.authenticationMethodsRegistrationCampaign Configured: 2026-05-11T18:08Z (via Tenant Admin SP using Policy.ReadWrite.AuthenticationMethod scope, after manifest expansion + Cascades re-consent same day) Setting: excludeTargets: [{id: "0674f0bc-6ff4-49c7-802d-2abf591ba371", targetType: "group"}]

This is a UX setting only — it does not weaken the security posture. It simply prevents Entra from prompting a user-friendly registration flow that the user can't complete.

SSPR (Self-Service Password Reset) scope exclusion

Caregivers are also excluded from SSPR registration enforcement. SSPR is a tenant-level feature configured at Entra → Protection → Password reset; it is independent of CA policies and the Authentication Methods Registration Campaign. With SSPR scoped to "All users" (the default), Entra interrupts every browser sign-in by an unregistered user with the "Let's keep your account secure" page until the user registers SSPR security info. Caregivers have no usable SSPR method (shared phones have no per-user SIM/email) and cannot complete this registration.

Group: SG-SSPR-Eligible (id d6044864-a0ef-4c30-ba37-cdba7074437e), created 2026-05-11. Contains the 25 currently-enabled human office and clinical staff. Caregiver users (SG-Caregivers-Pilot membership) and all service / shared-mailbox accounts are intentionally excluded from this group.

Setting: Entra portal → Protection → Password reset → Properties → "Self service password reset enabled" set to Selected → SG-SSPR-Eligible (was previously "All"). Configured by Howard via portal post-2026-05-11 (Graph does not expose a clean SSPR-scope endpoint).

Security implication: None. SSPR is a recovery mechanism (letting a user reset their own forgotten password), not an attack-prevention mechanism. Excluding caregivers from SSPR does not weaken protection against unauthorized sign-ins — that protection comes from the four CA layers above. Caregiver password resets are admin-initiated via the Entra portal as needed.

Future direction: SG-SSPR-Eligible is the off-ramp for the eventual SSPR retirement. As each office department gets its security hardening pass, individual users will be evaluated for SSPR need vs. admin-managed reset and removed from the group. Eventually the group can shrink to admins-only or be deleted entirely with SSPR scoped to None.

Residual risks (accepted)

The following risks are knowingly accepted under this architecture. Acceptance was reviewed against §164.308(a)(1)(ii)(B) (Risk Management) and the controls above were determined to be reasonable and appropriate compensation.

Residual risk Compensating mitigation Acceptance rationale
Stolen caregiver password used by an attacker physically present at Cascades, with a stolen corporate phone The phone is in Shared Device Mode, locked, requires the phone's lock-screen passcode to unlock, and any sign-in is auditable and attributable. Phone loss is reportable per §164.404 (Breach Notification). Phone wipe is one click in Intune. Physical presence + stolen device + password is a multi-step attack with high probability of detection; the residual is comparable to risks accepted by covered entities of this size in nearly all designs.
Caregiver shares password with coworker informally This is a workforce-policy violation regardless of MFA. Addressed via §164.308(a)(5) workforce training, NOT via technical controls. MFA on shared phones would not prevent password-sharing if the second factor is also shared. Out of scope for technical safeguards; covered by training.
Identity Protection misses a real attack pattern Microsoft's risk engine is constantly updated and is sampled by every customer. Cascades' specific sign-in pattern (consistent IP, consistent device, predictable cadence) is exactly the kind of baseline that makes anomaly detection effective here. Best available behavioral-detection control; no better alternative without P2 licensing.
Layer 2 (device compliance) is misconfigured or bypassed Compliance policy is monitored; any device exiting compliance is automatically blocked. Reviewed quarterly per this document's review cadence. Active monitoring + automated enforcement reduces drift risk to negligible.

Things that MUST remain true for this architecture to stay HIPAA-defensible

If any of these become false, the architecture must be reviewed and either restored or re-designed before continued use:

  1. CSC - Block caregivers off Cascades network remains Enabled.
  2. CSC - Block caregivers on non-compliant device remains Enabled. (NOT Report-only.)
  3. CSC - Caregiver sign-in frequency 8h remains Enabled.
  4. The Cascades named location is correctly populated with current public IPs 72.211.21.217/32 and 184.191.143.62/32. If Cascades' ISP changes the public IP, the named location must be updated before the change, or all caregiver sign-ins will be blocked.
  5. Compliance policy CSC - Android Compliance remains enforced against the shared-phone group.
  6. Shared Device Mode (profileType: Shared) remains the enrollment type for caregiver phones. If a phone shows profileType: RegisteredDevice instead, SDM is not active and Layer 3 (session restriction / auto-logoff) is broken.
  7. Sign-in logs are reviewed at least monthly for caregiver-account anomalies (volume spikes, unusual IPs that aren't blocked but flagged, repeated MFA-challenge failures indicating risk events).
  8. No new MFA-requiring CA policy is added without considering caregiver impact. Any CA policy that targets All Users with mfa grant could trigger registration nudges or de-facto blocks against caregivers — by design, the latter is acceptable, the former is not.

Items not in this document (separate HIPAA findings)

These are independent gaps tracked elsewhere; they predate and are not introduced by this architecture:

  • Microsoft BAA not yet signed. Required under §164.308(b)(1). Tracked in docs/cloud/m365.md:288.
  • ALIS BAA not yet verified. Required under §164.308(b)(1). Tracked in docs/billing-log.md:254.

Both must be in place before treating any of this as a complete HIPAA program.

Notes / future enhancements

  • If Cascades acquires Entra ID P2 licensing in the future (~$9/user/month for the caregivers group), this architecture should be revisited. The most direct improvement is to clone the two risk-based MFA policies as caregiver-targeted block-on-risk policies (which the current attempt failed with HTTP 400 error 1039). That would convert the Layer 4 de-facto block into an explicit block, simplifying the policy story and making the architecture easier to explain to auditors.

  • The architecture relies on caregivers being unable to register MFA. If a caregiver does end up registering MFA (e.g., they're added to a non-caregiver group that has its own MFA registration push, or they self-register via mysignins.microsoft.com), the de-facto-block path in Layer 4 changes to an actual MFA challenge — which they might satisfy. Periodically audit SG-Caregivers-Pilot member auth methods to confirm none have registered.

  • Document the workforce-training corollary. §164.308(a)(5) (Security Awareness and Training) is the policy backstop for the residual risks accepted above (especially password-sharing). Training documentation should reflect that caregivers' shared phones operate without MFA because of the layered technical controls; training should explicitly cover phone-loss reporting and password-sharing prohibition.

Audit trail

Date Change By Verification
2026-04-29 CA policy CSC - Block caregivers off Cascades network created Enabled Howard Enos Session log 2026-04-29-howard-cascades-bypass-pilot-phase-b-buildout.md
2026-04-29 CA policies CSC - Block caregivers on non-compliant device and CSC - Caregiver sign-in frequency 8h created (compliance policy initially Report-only) Howard Enos Session log 2026-04-29-howard-cascades-bypass-pilot-phase-b-buildout.md
2026-05-08 SDM enrollment activated on first pilot phones — profileType: Shared confirmed Howard Enos Session log 2026-05-08-howard-cascades-sdm-token-success-and-alis-sso.md
2026-05-11 CSC - Block caregivers on non-compliant device flipped Report-only → Enabled Howard Enos Session log 2026-05-11-howard-cascades-mhs-web-link-tiles-fix.md; Graph modifiedDateTime: 2026-05-11T18:06:21.9069392Z
2026-05-11 Registration Campaign exclusion for SG-Caregivers-Pilot added Howard Enos Session log 2026-05-11-howard-cascades-mhs-web-link-tiles-fix.md; manifest scope Policy.ReadWrite.AuthenticationMethod granted to Tenant Admin SP same day
2026-05-11 SG-SSPR-Eligible group created (25 human staff members) for SSPR scope migration off-ramp Howard Enos Session log 2026-05-11-howard-cascades-mhs-web-link-tiles-fix.md; group id d6044864-a0ef-4c30-ba37-cdba7074437e
2026-05-11 SSPR scope changed from "All" to "Selected: SG-SSPR-Eligible" (portal) — caregivers no longer interrupted with SSPR registration prompt Howard Enos (record verification after portal action)
2026-05-11 Full device clean-slate: 4 phones wiped (factory reset via Intune), 6 Entra Android device records deleted (4 phones + 2 orphans). Manifest expanded to add DeviceManagementManagedDevices.PrivilegedOperations.All and Device.ReadWrite.All (Tenant Admin SP now holds 18 Graph roles). Howard Enos Session log 2026-05-11-howard-cascades-mhs-web-link-tiles-fix.md Part 4
2026-05-11 Caregiver fleet re-enrolled (~17 unique SDM phones). ALIS SSO end-to-end validated on CSC-R9TW207FSXA as pilot.test — silent SSO from MHS tile through Entra to ALIS. Cosmetic MHS half-screen rendering issue on majority of phones identified as Samsung A14 + MHS aspect ratio interaction; deferred to Knox OEMConfig in next session. MHS App Configuration Policy 27683709-… created and assigned (no effect on scaling, kept in tenant). Manifest expanded to add DeviceManagementApps.ReadWrite.All (SP now at 19 Graph roles). Howard Enos Session log Part 5
2026-05-11 This document created Howard Enos (this file)
Reference in New Issue View Git Blame Copy Permalink