Azure Bastion Checklist for CMMC Level 2

Admin access is where solid Azure security often breaks down. One public RDP port, one shared admin account, or one weak exception can undo months of hardening.

If you handle CUI in Azure, I treat an Azure Bastion checklist as part security design, part audit prep. The real goal is simple, controlled admin access that I can prove with logs, reviews, and written procedures.

Where Azure Bastion fits in a Level 2 environment

I use Azure Bastion as a controlled front door for Windows and Linux administration over private IP addresses. That matters because it removes the usual public RDP and SSH exposure, and it ties access to Azure identities instead of a loose network path.

Still, Azure-native best practice and CMMC Level 2 mapping are not the same thing. Native best practice asks whether I hardened the service well. CMMC asks whether I can show that remote access is controlled, monitored, limited to authorized users, protected with MFA, and backed by policy and evidence.

For admin access, the strongest tie is CMMC AC.L2-3.1.12, which focuses on monitoring and controlling remote access sessions. Bastion also supports wider Level 2 expectations around least privilege, identity, and audit trails. Microsoft’s Technical Reference Guide for CMMC 2.0 is useful for that mapping, and this practical bastion host guidance for NIST SP 800-171 and CMMC helps frame the architecture.

Azure Bastion can support CMMC objectives, but it does not replace identity governance, logging, access reviews, or documented procedures.

That distinction matters during assessment. An assessor won’t stop at a Bastion deployment screenshot. I want to show who connected, how they authenticated, what role they had, what logs were retained, and which procedure governed the session.

My Azure Bastion checklist for controlled admin access

When I review a tenant, I start with the access path itself, then I work outward into identity, logging, and evidence. This keeps the build tight and the documentation clean.

Identity, MFA, and least privilege

• Every administrator uses a named Entra ID account. I verify there are no shared admin identities, no shared local admin passwords, and no long-lived SSH keys living outside policy. For proof, I keep role assignment exports, admin account standards, and screenshots or JSON exports from Entra.
• MFA is required for all privileged access. I check Conditional Access policies, test sign-ins, and document how emergency access accounts are protected and monitored. For evidence, I retain policy exports, sign-in logs, exception approvals, and break-glass procedures.
• Privileged roles should be just-in-time, not always on. I look for Microsoft Entra ID PIM with approval, time limits, and role scoping that matches job duties. I keep PIM settings, activation logs, approval records, and quarterly access review sign-offs.
• Admin sessions should start from managed devices only. That’s where Endpoint Security and Device Hardening matter, because a secure jump path still fails if the admin laptop is weak. I retain Intune compliance reports, Defender posture reports, and the written workstation baseline.

Network design and the Bastion access path

• Target VMs should not have public IP addresses for admin access. I verify that RDP and SSH are reachable only over private networking, and that NSGs or firewalls block Internet exposure. For proof, I keep VM inventories, Azure Policy compliance results, NSG exports, and a dated network diagram.
• Bastion needs a deliberate landing zone. I confirm it sits in the required AzureBastionSubnet, uses approved RBAC, and is deployed in the right subscription and region for the workload. I keep the IaC template, deployment record, subnet details, and change ticket.
• I remove side doors wherever possible. If admins can still reach servers through direct VPN RDP, ad hoc jump boxes, or vendor tunnels, Bastion stops being the control point. I retain the standard operating procedure, the approved remote access matrix, and a documented exception register for any alternate path.
• Optional Bastion features need policy decisions, not guesswork. If native client support, file transfer, or session recording are available in your SKU and licensing model, I decide whether each one is allowed, needed, or disabled. I keep the configuration snapshot and the approval note that supports the choice.

I also like Azure Policy here, because it catches drift before it becomes a finding. If a new VM picks up a public IP or an admin rule slips into an NSG, I want that flagged fast.

Logging, alerting, and evidence retention

• Bastion diagnostic logs, Azure Activity Logs, Entra sign-in logs, Conditional Access results, and PIM audit logs should all flow to a central workspace. I usually send them into Log Analytics, and some clients also use Sentinel for analytics and cases. For proof, I keep diagnostic settings exports, workspace retention settings, and sample log queries.
• Bastion logs connection events, but they don’t tell the full story of what happened inside the host. Because of that, I also collect Windows and Linux authentication logs, host security events, and endpoint telemetry. Where available and approved, session recording adds stronger support, but I still pair it with host logs.
• Alerts need to match admin risk. I create detections for failed MFA, unusual sign-in patterns, after-hours privileged access, Bastion configuration changes, and repeated role activations. I keep alert definitions, incident tickets, analyst notes, and closure records.
• Retention has to match policy, contract terms, and assessor expectations. I don’t rely on live logs alone, because workspace settings change and old data can roll off. I keep evidence copies in controlled storage, often with immutability or archive controls, plus a written retention schedule.

For network telemetry, I avoid building new designs around NSG flow logs in 2026. Microsoft is retiring that path, so I prefer current options such as virtual network flow logging or other approved telemetry sources that fit the environment.

How I keep evidence ready for an assessor

A strong build can still create a weak assessment if the proof is scattered. I keep Bastion evidence in three buckets: design records, operating records, and governance records. That gives me a simple trail from policy to configuration to daily use.

Design records include diagrams, IaC templates, approved architectures, and the SSP language that explains the admin access method. Operating records include sign-in logs, PIM activations, change tickets, alert history, and monthly or quarterly reviews. Governance records include the remote access policy, access review procedure, exception handling, emergency account procedure, and training acknowledgments.

Screenshots help, but I don’t stop there. I prefer exports, time-stamped reports, saved queries, and ticket references because they hold up better in an audit trail. When I want a Microsoft source for wording or mapping support, I also check the September 2024 preview guide for CMMC Level 2.

The final piece is procedure. I document who can request admin access, who approves it, how long it lasts, how I review it, and what I do when an exception appears. That’s what turns a good Azure setup into something I can defend under real scrutiny.

This control pattern pays off beyond compliance

When I work in Small Business IT, I don’t isolate Bastion from the rest of the stack. The same Cloud Infrastructure rules should carry into Office 365 Migration projects, Data Center Technology refresh work, and daily Cloud Management. That approach also strengthens Cybersecurity Services, because Endpoint Security and Device Hardening on admin workstations matter as much as the jump point itself.

If I support Restaurant POS Support or Kitchen Technology Solutions, I keep the same controlled access model for vendors and internal admins. That’s how Innovative IT Solutions become Tailored Technology Services instead of one-off fixes. Strong Technology Consulting turns me into a real Business Technology Partner, because Infrastructure Optimization, Digital Transformation, IT Strategy for SMBs, Secure Cloud Architecture, Managed IT for Small Business, and Business Continuity & Security all depend on disciplined administrative access.

Conclusion

One weak admin path can erase a lot of good security work. A disciplined Azure Bastion checklist closes that gap when I pair it with MFA, least privilege, centralized logging, retained evidence, and written procedures.

For CMMC Level 2, the winning position is clear and defensible. I can show who had access, how they got it, what they were allowed to do, what was logged, and how the organization reviewed it. That’s the standard I want before an assessor ever asks for proof.