Identity-first cloud migration for a HIPAA-regulated firm
Moving a small regulated firm to a fully cloud-native stack, with identity as the security perimeter and compliance built in from day one.
At a glance
- Role
- Lead architect and implementer
- Environment
- Cloud identity, device management, Microsoft 365
- Approach
- Staged rollout with validation at each step
- Evidence
- Decision log and GRC workbook
Context
A small advisory firm that handles regulated health information wanted to retire its remaining on-premises dependencies and move fully to the cloud. Years of organic growth had left a cluttered directory, inconsistent identity controls, and no single, documented picture of who could access what.
The goal was not just to “lift and shift.” It was to rebuild identity and device management so that security and compliance requirements were designed in from the start, not added later.
Goals
- Make identity the perimeter: access decisions based on who the user is, the state of their device, and the context of the sign-in, instead of trust in a network location.
- Leave behind a directory that is small, documented, and governed.
- Produce work that doubles as compliance evidence for HIPAA Security Rule obligations.
- Do all of it without disrupting a small team that cannot afford downtime.
Approach
1. Clean before you build. The directory was consolidated down to current staff and documented service accounts. Every remaining group got a purpose, and guardrails were added: only administrators can create groups, and groups expire unless renewed.
2. Close the obvious gaps first. A tenant-wide MFA audit identified every account without strong authentication, and each one was remediated before more advanced policies were layered on top.
3. Design access policy as a set, not one rule at a time. Conditional access policies were designed together, so each one has a clear job and the set has no gaps or overlaps. They were rolled out in stages, with impact validated before every step.
4. Plan for the day it breaks. Emergency-access (“break-glass”) accounts are protected with hardware security keys, excluded from policies that could lock everyone out, and monitored with sign-in alerts. The alerting was tested to measure how quickly a sign-in is actually reported, not just assumed to work.
5. Bring devices into the picture. Windows and macOS devices are enrolled in device management with compliance policies and endpoint protection, so device health can become part of the access decision.
Key decisions
- Identity perimeter over a traditional VPN. A VPN extends trust to anything on the network. With identity as the perimeter, every request is evaluated on its own.
- Deny-by-default access for the few private resources that remain, instead of a VPN that would grant broad network access.
- Staged rollouts over a “big bang.” Every policy is validated before it is enforced, because a small firm has no spare capacity to absorb a lockout.
- Separate admin accounts for privileged work, so everyday accounts never carry administrator rights.
Outcome
The first phase is complete: modernized licensing, MFA remediated across the organization, a governed directory, and device management validated on both Windows and macOS. Every decision is recorded in a decision log, which serves as audit evidence alongside the GRC workbook.
What’s next
Finish enforcing the access policy set, retire the remaining on-premises dependencies, and track proposed HIPAA Security Rule changes that could turn today’s “addressable” controls into required ones.