This post gives a practical implementation playbook for satisfying NIST SP 800-171 Rev.2 / CMMC 2.0 Level 2 control MA.L2-3.7.5: enforce multi-factor authentication (MFA) for nonlocal maintenance and automatically terminate or limit remote maintenance sessions across AWS, Azure, and GCP. It focuses on concrete steps, policy snippets, automation ideas, and small-business scenarios so you can implement and validate the control quickly and reliably.
Why this control matters (mapping to the Compliance Framework)
MA.L2-3.7.5 requires that nonlocal maintenance (remote admin access, vendor troubleshooting, etc.) be strongly authenticated and sessions be automatically terminated or constrained to reduce exposure. The objectives are simple: ensure an additional factor before granting privileged remote access, and reduce the time window that an attacker can operate with a legitimate session. For small organizations and integrators, this reduces risk of credential compromise, lateral movement, and long-duration exfiltration while meeting NIST/CMMC evidence requirements (policies, configuration, and logs).
Implementation pattern (high-level)
Across cloud providers the pattern is the same: 1) enforce MFA at the identity provider level for any account that can perform nonlocal maintenance (console, SSH jump hosts, APIs used for maintenance); 2) limit or bound session lifetime for interactive and API sessions (STS/AssumeRole sessions, SSO session lifespan, refresh tokens); 3) provide a mechanism to force reauthentication (revoke refresh tokens, disable SSO assignment, or rotate credentials) and log events for audit. Use short-lived, federated access (SSO + STS or OAuth tokens) rather than long-lived account credentials whenever possible.
AWS — concrete steps and examples
Recommended steps for AWS:
- Use AWS IAM Identity Center (AWS SSO) or an external IdP (Azure AD, Okta) for console and federated access. Do not rely on root account credentials for daily management. - Enforce MFA on the IdP and require MFA in IAM policies for sensitive actions. Example IAM policy denying any action unless MFA is present:
{
"Version": "2012-10-17",
"Statement": [{
"Effect": "Deny",
"Action": "*",
"Resource": "*",
"Condition": { "Bool": { "aws:MultiFactorAuthPresent": "false" } }
}]
}
- Set role MaximumSessionDuration to a conservative bound for privileged roles (example: 3600 seconds = 1 hour):
aws iam update-role --role-name AdminRole --max-session-duration 3600- For SSO-managed sessions use the Identity Center Settings to set the session duration to an appropriate value (e.g., 1 hour interactive for admins, 15–30 minutes for maintenance consoles). - Use STS/AssumeRole session DurationSeconds for programmatic nonlocal maintenance and set low TTLs (e.g., 900–3600 seconds). - For forced logout or emergency session termination, prefer central IdP actions (disable the user in the IdP, revoke tokens) because AWS does not offer a simple "kill session" API for console sessions. If you use a third-party IdP, revoking the user's session there will effectively terminate console access quickly. Also monitor ConsoleLogin and AssumeRole events in CloudTrail and alert on unusually long or stale sessions.
Azure — Conditional Access, PIM, and session controls
Azure provides rich built-in controls for MFA and automated sign-in/session controls:
- Use Azure AD Conditional Access to require MFA for nonlocal access and for administrative roles. Example policy: apply to All Cloud Apps, exclude trusted on-premises network ranges (if applicable), require "Grant -> Require multi-factor authentication". - Use the "Sign-in frequency" and "Persistent browser session" controls in Conditional Access to limit how long a browser/console session persists before reauthentication is required. Set sign-in frequency to a conservative value for administrative access (e.g., 1 hour) or require reauthentication for each elevation.
- For role elevation, enforce Azure AD Privileged Identity Management (PIM); require MFA at activation and limit the "Activation time" to small windows (e.g., 2 hours) and require justification and approval workflows. - To forcibly terminate sessions, use Microsoft Graph / Azure AD PowerShell to revoke refresh tokens for a user or to disable a user account, which forces reauthentication:
# PowerShell (AzureAD module)
Revoke-AzureADUserAllRefreshToken -ObjectId <user-object-id>
- Document your Conditional Access policies and collect SignIn logs to show compliance. For small businesses, combine MFA + Conditional Access with PIM so vendor or remote maintenance accounts must request activation and be time-limited.
GCP — Workspace/GCP Identity, short-lived credentials, and session rules
GCP consolidates authentication in Google Workspace / Cloud Identity and Cloud IAM:
- Enforce 2-Step Verification (2SV) at the organization level via Google Admin console (Security → Authentication → 2-step verification) and require security keys or authenticator apps for privileged users. Avoid SMS-based 2SV when possible. - Use Access Context Manager / Context-Aware Access to enforce session controls and require reauthentication based on device posture or location. In the Google Workspace Admin console you can set session length for web sessions to force reauthentication after a set interval.
- For programmatic maintenance, use short-lived credentials (impersonation of service accounts or the IAM Credentials API) instead of long-lived keys. Short-lived access tokens default to one hour; configure your automation to request tokens with minimal TTL. - To force a sign-out when needed, revoke a user's refresh tokens via the Admin SDK or the Workspace Admin console, which forces reauthentication of all web/console sessions.
Small-business scenarios and automation ideas
Scenario 1 — Small MSP performing vendor troubleshooting: create a dedicated maintenance role in each cloud account that requires MFA via your IdP and has a max session duration of 1 hour. Require MSP engineers to use SSO and PIM-style elevation; keep audit trails in CloudTrail/SignIn logs and require ticketing reference in activation justification. Scenario 2 — Developer needs remote SSH into a cloud VM for debugging: avoid SSH over long-lived keys; use ephemeral SSH via OS Login with 2FA, or generate ephemeral keys via your SSO/IdP and rotate them automatically (bastion with short-lived certificates). Automations: implement CloudWatch Events / EventBridge + Lambda (AWS) or Azure Logic Apps + Functions to detect suspicious long-lived sessions (based on lack of new activity or stale token age) and automatically disable IdP assignment or rotate credentials; then generate an incident and force reauthentication.
Risks, compliance tips, and best practices
If you do not enforce MFA and session limits for nonlocal maintenance, attackers who compromise a single set of credentials can maintain persistent access for a long time and perform high-impact actions without reauthentication—this materially increases the risk of lateral movement and data exfiltration and produces audit failures under NIST/CMMC. Compliance tips: codify MFA/session policies in your System Security Plan (SSP) and procedures, maintain evidence (screenshots/policies + logs), and run periodic tests (simulate vendor maintenance, check that a revoked refresh token causes immediate reauth). Best practices: prefer hardware or FIDO2 tokens for privileged users, enforce MFA at the IdP rather than per-resource when possible, use short-lived federated access tokens for automation, and log all maintenance activity to a centralized immutable log store for audit and incident response.
Summary: to meet MA.L2-3.7.5 you must combine IdP-enforced MFA, provider session-duration controls, short-lived credentials, and an operational capability to force reauthentication or revoke sessions. On AWS use IAM/Identity Center policies and role max-session-duration; on Azure use Conditional Access and PIM with token revocation; on GCP enforce 2SV, use Access Context Manager and short-lived tokens. Document the configuration and retain logs as evidence; for small businesses, start with SSO + MFA + short STS token lifetimes and build automated detection + revocation workflows to achieve both security and compliance.
