Azure MFA does not end admin sessions. It proves that a person passed multifactor authentication when establishing access, but it does not automatically close an RDP, SSH, VPN, Azure Bastion, or remote-support connection after maintenance is finished. For NIST SP 800-171 Rev. 2 and CMMC 2.0 Level 2 practice MA.L2-3.7.5, you need both controls: MFA to establish nonlocal maintenance access and a defined process or technical mechanism to terminate that external connection when the work is complete.
What is the myth behind “azure mfa does not end admin sessions”?
The myth is that enabling Microsoft Entra MFA, especially through Conditional Access, fully satisfies MA.L2-3.7.5 because every administrator must approve a sign-in prompt before accessing Azure. MFA is necessary, but it addresses only the first half of the practice: authenticating the person who starts the remote maintenance session.
The second half is operational: when you finish patching a server, troubleshooting a line-of-business application, or making a network change from home, the connection used for that maintenance must be shut down. If your RDP window stays connected, your SSH shell remains open, or your VPN remains active until the end of the day, the MFA event that occurred hours earlier does not close that exposure.
Why is this misconception so widespread?
Azure administrators see an MFA prompt, a successful Conditional Access result, and a Microsoft Entra sign-in log. Those are visible, reassuring controls, and they are often what a compliance assessor asks to see first. By contrast, session termination is spread across the tools used to perform maintenance: a VPN client, Azure Bastion, an RDP client, an SSH terminal, a remote support product, or a privileged jump host.
The wording “session” also causes confusion. In Microsoft Entra, a session can mean a browser or token session governed by Conditional Access session controls. In MA.L2-3.7.5, the practical concern is the nonlocal maintenance connection from an external network. Requiring sign-in again every eight hours can reduce token persistence, but it is not the same thing as closing an already-established RDP or SSH connection.
A sole IT administrator is especially likely to combine these concepts because the same person configures Conditional Access, supports users, patches servers, and writes the evidence package. It is easy to assume that a strong identity control covers every later action. For this practice, document the handoff: Entra MFA authorizes the start of maintenance; the access path and administrator procedure end it.
What does MA.L2-3.7.5 actually require?
NIST SP 800-171 Rev. 2 requirement 3.7.5 states: “Require multifactor authentication to establish nonlocal maintenance sessions via external network connections and terminate such connections when nonlocal maintenance is complete.” CMMC 2.0 Level 2 maps this requirement to MA.L2-3.7.5.
That sentence contains two independently testable objectives:
- MFA must establish the session. A maintenance user connecting from outside the organization’s network must use at least two factors, such as a password plus Microsoft Authenticator approval, FIDO2 security key, certificate, or biometric-backed Windows Hello for Business sign-in.
- The external connection must end when work ends. The administrator must close the VPN, Bastion, RDP, SSH, or other remote-maintenance path after completing the authorized task.
The control applies to maintenance activities conducted through external network connections, such as an administrator connecting over the internet from home or a managed service technician connecting from another location. It does not mean every Azure Portal activity is automatically “maintenance.” However, if you use Azure to reach systems for patching, diagnostics, repairs, configuration changes, or similar upkeep, treat that access path as in scope unless your documented system boundary says otherwise.
| Azure-related control | What it helps prove | What it does not prove by itself |
|---|---|---|
| Microsoft Entra Conditional Access requiring MFA | The maintenance user authenticated with MFA before access. | That an active VPN, RDP, SSH, or Bastion connection was closed after work. |
| Microsoft Entra Privileged Identity Management | Privileged Azure roles were activated only when needed and can require MFA. | That the remote operating-system session was terminated. |
| Azure Bastion idle timeout | An unattended Bastion session has a technical timeout backstop. | That the administrator deliberately ended access immediately when maintenance finished. |
| Defender for Cloud just-in-time VM access | New inbound RDP or SSH access is limited to approved ports and a limited window. | That an already-established session necessarily ended when the JIT rule expired. |
How should a one-person IT team implement this in Azure?
1. Identify every remote maintenance path you actually use
Start with reality, not an ideal diagram. List how you reach in-scope systems from outside the office: Azure Bastion to Windows VMs, SSH to Linux VMs, point-to-site VPN followed by RDP, a remote support tool, firewall administration over VPN, or an outsourced technician’s connection. Include the management path to on-premises systems if Azure VPN or Entra authentication is part of it.
For each path, write down the MFA enforcement point and the termination action. A small table in your system security plan or maintenance procedure is sufficient if it reflects actual practice.
2. Require MFA before the maintenance connection is established
In Microsoft Entra Conditional Access, create a policy for a dedicated maintenance-administrators group. Target the relevant cloud applications, such as Microsoft Azure Management, and any VPN or remote-access application that uses Entra ID authentication. Under Grant controls, select Require multifactor authentication. Exclude only emergency access accounts that are separately protected, monitored, and documented.
Use Privileged Identity Management where your licensing and environment support it. Make standing Azure roles eligible rather than permanently active, require MFA for activation, and set a short activation duration appropriate to your work pattern. PIM is useful evidence of privileged access discipline, but do not write that it terminates the underlying maintenance connection unless you have tested that exact integration.
3. Use a remote-access design that makes closure practical
For Azure VMs, Azure Bastion is often easier for a solo administrator to govern than exposing public RDP or SSH. Keep VM management ports closed to the internet, require MFA to reach Azure management resources, and configure a reasonable Bastion idle timeout as a safety net. A 30-minute idle timeout may be appropriate for routine work; choose a value that fits your maintenance tasks and document why.
If you use point-to-site VPN, require MFA through the VPN’s identity provider and make disconnecting the VPN part of the closeout procedure. If your support tool has a technician console, require MFA there and use its session-end or sign-out function when the ticket is complete. Do not rely on simply closing a browser tab if the support session can remain active in the background.
4. Define the exact closeout action for each connection type
Your procedure should use verbs an assessor and a backup administrator can verify: exit, log off, disconnect, and verify. “The session times out eventually” is not a complete closeout instruction. Timeouts are valuable compensating safeguards for abandoned sessions, but MA.L2-3.7.5 expects the connection to be shut down when maintenance is complete.
Remote maintenance closeout example Azure Bastion to Windows VM: 1. Save work and close administrative tools. 2. Log off the Windows session; do not leave it merely disconnected. 3. Close the Azure Bastion session. 4. Disconnect the point-to-site VPN, if one was used. 5. Update the maintenance ticket with the completion time. SSH to Linux VM: 1. End elevated work and type: exit 2. Confirm the SSH client has disconnected. 3. Disconnect the VPN, if one was used. 4. Record the completion time in the ticket.
For Windows systems where a disconnected RDP session may persist, use quser to review sessions and logoff <sessionID> when appropriate. This is particularly important when a server has multiple administrators or when you hand work off to a vendor.
5. Keep evidence that demonstrates both halves of the practice
Save or export the Conditional Access policy showing MFA requirements, the maintenance-group membership, and relevant Microsoft Entra sign-in logs. Keep your Azure Bastion configuration or VPN configuration, including timeout settings where available. Then retain maintenance tickets, change records, or a simple maintenance log that identifies the system, administrator, start and completion time, work performed, and confirmation that the remote connection was closed.
Once per quarter, test one representative path from outside your network. Confirm that MFA is challenged before access, perform a brief maintenance action, log off and disconnect, then verify the session no longer appears in the relevant Bastion, VPN, support-tool, or server session view. That test turns a written procedure into credible evidence.
What related misconceptions should you avoid?
“A Conditional Access sign-in frequency ends my RDP session.”
Not necessarily. Sign-in frequency controls when Microsoft Entra requires reauthentication for supported token-based access. It can be a useful session-management setting, but it should not be your only evidence that remote maintenance connections are terminated. Test the behavior of your actual VPN, Bastion, RDP, and SSH workflows.
“Just-in-time VM access closes existing sessions when the access window expires.”
Just-in-time access reduces exposure by temporarily allowing new inbound connections. Because network controls can be stateful, removal of an access rule should not be assumed to terminate an established session. Use JIT to limit new access, then separately log off and disconnect when the work is done.
“If the admin is on the corporate network, MA.L2-3.7.5 never applies.”
The practice specifically addresses nonlocal maintenance through external network connections. A remote employee connected from home over the internet is plainly in scope even if a VPN eventually places them on an internal subnet. Document your access paths and apply the control based on how maintenance is established, not only on the IP address visible after connection.
Next step: create a one-page remote-maintenance closeout procedure today and test it against the Azure access path you use most often.
