claudetools/clients/cascades-tucson/docs/security/hipaa-caregiver-controls.md

# 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 — resolved 2026-05-14.** Covered automatically by the Microsoft Customer Agreement for Business plan subscribers. No separate acceptance required.
- **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) |