If your organization handles Controlled Unclassified Information (CUI), multi-factor authentication (MFA) in Microsoft GCC High is a required control for CMMC Level 2 certification, and if it’s missing or inconsistently enforced during your C3PAO assessment, you won’t pass.

This guide walks through how to configure MFA in Microsoft Entra ID within a GCC High environment, from identifying gaps in coverage to enforcing policies with Conditional Access. Along the way, we’ll map each step to NIST SP 800-171 practice 3.5.3 and call out the GCC High-specific nuances that tend to trip teams up when they rely on commercial Microsoft documentation.

Why MFA cannot go on a POA&M

Under CMMC Level 2, MFA is not something you can defer. If it isn’t fully implemented and consistently enforced at the time of your assessment, it results in a failed assessment, not a finding you can remediate later.

That requirement comes from NIST SP 800-171 practice 3.5.3 (IA.L2-3.5.3): Use multifactor authentication for local and network access to privileged accounts and for network access to non-privileged accounts.

In practice, assessors are looking for four things:

• MFA is used for local access to privileged accounts
• MFA is used for network access to privileged accounts
• MFA is used for network access to non-privileged accounts
• The authentication methods meet NIST SP 800-63B assurance levels

In GCC High environments, most teams have the network side covered once Conditional Access is in place. Where things tend to break down is local privileged access and the strength of the authentication methods themselves.

MFA in GCC High vs. Microsoft 365 Commercial

GCC High is a separate sovereign cloud environment, not just a variation of commercial Microsoft 365. That separation introduces some important differences that directly impact MFA configuration.

The admin portals are different. In GCC High, you’ll use:

• https://entra.microsoft.us (Microsoft Entra admin center)
• https://portal.azure.us (Azure Government portal)
• https://admin.microsoft365.us (Microsoft 365 admin center)

If you try to sign in through commercial endpoints, your accounts won’t be recognized.

MFA configurations also don’t carry over from commercial tenants. If you migrated to GCC High, users had to re-register their authentication methods from scratch.

It’s also worth noting that Microsoft’s mandatory MFA rollout for commercial tenants does not apply to GCC High. If MFA hasn’t been explicitly configured in your environment, there’s a good chance it isn’t being enforced at all.

Finally, feature availability and third-party integrations can differ. Some tools aren’t authorized in FedRAMP High environments, and new authentication features typically appear in commercial before they reach GCC High.

The short version is that copying commercial guidance often leads to gaps. GCC High needs to be configured intentionally.

Step 1: Identify unprotected users before enforcement

Before you start turning policies on, you need a clear picture of your current state.

Specifically, you’re trying to answer a simple question: which users don’t have MFA today?

You can find this in the Entra admin center or export it using Microsoft Graph PowerShell.

For GCC High, make sure you're connecting to the USGov endpoint — this is where commercial Microsoft guidance will quietly lead you in the wrong direction.

# Install the module if not already present
Install-Module Microsoft.Graph -Scope CurrentUser

# Connect to Microsoft Graph (GCC High endpoint)
Connect-MgGraph -Environment USGov -Scopes "UserAuthenticationMethod.Read.All", "User.Read.All"

# Export authentication method registration details
Get-MgBetaReportAuthenticationMethodUserRegistrationDetail -All |
    Select-Object UserPrincipalName, IsRegistered, IsMfaRegistered, MethodsRegistered |
    Export-Csv -Path "MFA_Audit.csv" -NoTypeInformation

To identify users without MFA:

Get-MgBetaReportAuthenticationMethodUserRegistrationDetail -All |
    Where-Object { $_.IsMfaRegistered -eq $false -and $_.IsEnabled -eq $true } |
    Select-Object UserPrincipalName, MethodsRegistered |
    Export-Csv -Path "No_MFA_Users.csv" -NoTypeInformation

The PowerShell output is especially useful because it doubles as evidence you can provide during your assessment.

Your goal here is to identify every active user without MFA coverage and close those gaps before enforcement begins.

Step 2: Enable strong authentication methods in Entra ID

Once you know where you stand, the next step is enabling the right authentication methods.

Start by enabling Microsoft Authenticator for all users and turning on number matching. This provides a consistent baseline and helps prevent accidental approvals.

From there, scope stronger methods to higher-risk users. Privileged accounts should have access to phishing-resistant options like FIDO2 security keys or certificate-based authentication, while standard users can remain on app-based MFA if appropriate.

At this stage, focus on coverage and alignment. Every user should have at least one approved method, and higher-risk accounts should have stronger options available.

Step 3: Enforce MFA registration across all users

After enabling authentication methods, you need to make sure users actually register them.

The MFA registration policy handles this by prompting users who haven’t enrolled yet and requiring them to complete setup within a defined period.

Without this step, users won’t register.

Step 4: Block password-only sign-ins with conditional access

This is the step that turns MFA from a configuration into an enforced control.

Conditional Access policies require MFA at sign-in. Without them, users can still authenticate with just a password.

At a minimum, you should configure:

• A baseline policy requiring MFA for all users across all applications
• A policy requiring phishing-resistant MFA for privileged roles

Roll these out in report-only mode first, validate the impact, and then switch them to enforced once you’re confident everything is working.

During an assessment, policies need to be active and applied consistently.

Step 5: Strengthen authentication with phishing-resistant MFA

At this point, MFA may be fully deployed. The next question is whether it’s strong enough.

Push-based MFA is widely used, but it can still be vulnerable to real-time phishing or repeated approval prompts. Assessors are increasingly aware of these limitations, especially for privileged access.

Phishing-resistant MFA methods address this by binding authentication to the application or session using cryptography. Instead of approving a prompt, the user is proving possession of a device or credential that cannot be replayed.

CMMC Level 2 does not explicitly require phishing-resistant MFA across all users, but expectations are shifting. For privileged accounts in particular, method strength is becoming part of how assessors evaluate whether MFA is implemented effectively, not just whether it exists.

Step 6: Close the local privileged access gap

Conditional Access covers network authentication, but it doesn’t apply to local logins on servers or other infrastructure.

That means administrators could still be accessing critical systems without MFA unless you’ve implemented additional controls. This is one of the most common gaps identified during assessments.

To address this, organizations typically use:

• Windows Hello for Business with TPM-backed credentials
• Privileged Access Workstations with MFA-protected jump access
• Smart cards or PIV authentication for server logins

Whatever approach you choose, it should be clearly implemented and documented in your System Security Plan (SSP).

Step 7: Generate evidence that reflects your current state

Once MFA is fully implemented, you need to be able to prove it.

Your evidence package should include:

• Authentication method configuration
• Conditional Access policies (enabled)
• MFA registration reports showing full coverage
• Sign-in logs demonstrating MFA enforcement
• SSP documentation aligned to IA.L2-3.5.3

The key is that your evidence reflects your current environment. If configurations change, your documentation needs to keep up.

Common MFA mistakes to avoid

Most MFA-related findings don’t come from complex technical issues. They tend to come from small gaps that are easy to miss but obvious to an assessor.

One of the most common is relying on Security Defaults instead of Conditional Access. Security Defaults can enable MFA in a basic way, but they don’t enforce it consistently across all users, applications, and scenarios. From an assessment perspective, that lack of consistency creates risk, and it’s usually flagged quickly.

Service accounts are another area that gets overlooked. Because they aren’t tied to individual users, they’re often excluded from MFA entirely. But assessors don’t distinguish between human and non-human identities when it comes to access control. If a service account can authenticate interactively, it either needs MFA or a clearly documented compensating control.

Legacy authentication is a frequent issue as well. Older protocols don’t support MFA, which means they can bypass your policies altogether. Even if everything else is configured correctly, leaving legacy authentication enabled creates a direct path around MFA enforcement.

Break-glass accounts can also raise concerns if they aren’t handled carefully. You do need emergency access accounts that are excluded from Conditional Access policies, but they should be limited, tightly controlled, and clearly documented. If they’re missing or loosely managed, it signals a lack of discipline in your access control strategy.

Another common problem is partial MFA coverage. It’s not enough to have MFA enabled for most users. If even a small number of active accounts are unprotected, that gap is enough to result in a finding.

Finally, teams often run into trouble by following commercial Microsoft guidance too closely. GCC High behaves differently in a number of ways, from portal access to feature availability. Those differences can introduce subtle misconfigurations that aren’t obvious until they’re tested during an assessment.

What MFA looks like during a CMMC assessment

By the time you get to a CMMC assessment, MFA isn’t something you’re configuring; it’s something you’re explaining.

An assessor isn’t going to ask whether MFA is enabled in theory. They’re going to look at how it’s enforced across your environment, how exceptions are handled, and whether what’s documented in your SSP matches what’s actually happening in your tenant.

That usually plays out in a few very specific ways. They’ll want to see your Conditional Access policies and confirm they’re active, not staged. They’ll review authentication method settings and how you’re handling privileged accounts. And they’ll often ask for evidence that MFA is consistently applied across your user population, not just configured at a high level.

Where teams tend to get stuck isn’t the configuration itself. It’s connecting all of those pieces in a way that’s clear, current, and easy to verify. MFA might be fully implemented, but the evidence lives in different places, was captured at different times, or no longer reflects the current state of the environment.

That’s the part of the process that’s easy to underestimate.

Secureframe Defense is built around making that validation step straightforward. It maintains a direct connection to your GCC High environment, so MFA enforcement, policy configuration, and user coverage are continuously tracked and mapped back to CMMC requirements like IA.L2-3.5.3.

So when those questions come up during an assessment, you’re not reconstructing how MFA works in your environment. You’re showing it as it exists today.

If you want to see what that looks like in practice, schedule a demo to walk through how Secureframe Defense monitors MFA enforcement and generates assessment-ready evidence in a GCC High environment.