09.20.2026

Technical Guide #6: Configuring Microsoft 365 for Compliance, MFA, Admin Roles, and Conditional Access

Microsoft 365 is where many federal contractors store email, documents, project records, and Controlled Unclassified Information (CUI). That makes identity and access configuration a central part of your security boundary.

Share this blog on:

Technical Guide 6 highlighted among compliance guides with Microsoft 365 security configuration checklist

By Josh Hammer

The default tenant configuration is not a compliance configuration. If you are preparing for CMMC 2.0 readiness, NIST SP 800-171, or another security review, you need to know which cloud you are using, who has administrative access, how users authenticate, which devices can connect, and what evidence proves each decision.

This guide shows the actual configuration path.

Important: Microsoft 365 is available in different cloud environments. The environment you use determines whether it is appropriate to store CUI. Confirm this before changing settings.

1. First, determine which Microsoft 365 cloud you are using

Do not begin by creating Conditional Access policies. First determine whether your tenant is commercial Microsoft 365, GCC, or GCC High.

Commercial Microsoft 365

Commercial Microsoft 365 is the standard tenant most businesses purchase. It is not designed to hold CUI for DoD work. Do not assume that buying a higher commercial license automatically changes the cloud boundary, data residency, personnel requirements, or export-control posture.

Microsoft 365 Government GCC High

Microsoft 365 Government GCC High is the environment DoD contractors generally use for CUI because it is designed around additional federal requirements involving data residency, screened personnel, and ITAR-related considerations.

GCC and GCC High are different environments. A contractor handling CUI may not be able to use GCC High as a reflex, however. The decision has cost, migration, licensing, support, and operational consequences.

Before migrating, confirm:

What information you actually handle.
Whether that information is CUI, ITAR-controlled, or another protected category.
Which contracts and clauses apply.
Whether your current environment can satisfy those requirements.
Whether moving the entire tenant is necessary or whether scope can be reduced.

Technical Guide #3 covers the data-scoping decision. Complete that analysis before choosing a platform.

Practical endpoint test

Look at the endpoint used when you authenticate.

Commercial tenants generally use commercial Microsoft Entra endpoints such as entra.microsoft.com.
GCC High tenants use government endpoints such as entra.microsoft.us.

This is a useful test, but it is not a substitute for confirming your tenant’s service description, licensing, contract, and data boundary. If you are unsure, stop and verify the environment before configuring anything.

Microsoft’s official guidance on Office 365 GCC High and DoD and CMMC for US Government environments should be part of that review.

2. Configure the four layers of MFA and access control

Once you know which tenant you are configuring, establish four separate layers. MFA alone is not enough. The objective is to control the user, the authentication method, the protocol, and the device.

Microsoft describes Conditional Access as an “if-then” policy engine: if a user requests access to a resource, then the tenant evaluates conditions and applies an access decision. See Microsoft’s Conditional Access overview.

Layer 1: Require MFA for everyone

Sign in to the Microsoft Entra admin center:
- Commercial: entra.microsoft.com
- GCC High: entra.microsoft.us
Select Entra ID.
Select Protection.
Select Conditional Access.
Select Policies.
Select New policy.
Name the policy descriptively. For example:

CA001 - Require MFA - All users - All cloud apps
Under Assignments, select Users.
Select All users.
Exclude only documented emergency access accounts and any carefully reviewed service accounts that cannot use interactive MFA.
Under Target resources or Cloud apps, select All cloud apps.
Under Access controls, select Grant.
Select Require multifactor authentication.
Select Select.
Set Enable policy to Report-only.
Select Create.

Before enforcement, use the What If tool on the Conditional Access Policies page. Test ordinary users, administrators, mobile users, service accounts, and emergency access accounts. Review the sign-in logs for unexpected exclusions or blocked applications.

After testing, edit the policy and change Enable policy to On.

Do not rely on Security Defaults as your compliance evidence. Security Defaults are a basic security switch. They do not give you the same policy specificity, scope documentation, or reviewable configuration as explicit Conditional Access policies. A reviewer should be able to see exactly which users, applications, conditions, and grant controls are in effect.

Layer 2: Require stronger authentication for administrators

Create a separate policy for privileged roles.

Go to Entra ID > Protection > Conditional Access > Policies.
Select New policy.
Name it:

CA002 - Phishing-resistant MFA - Privileged roles
Under Assignments > Users, select User and groups.
Select Directory roles.
Include roles such as:
- Global Administrator
- Privileged Role Administrator
- Exchange Administrator
- SharePoint Administrator
- Any custom administrative roles
Under Target resources, select All cloud apps or the administrative resources defined in your access plan.
Under Access controls > Grant, select Require authentication strength.
Select a phishing-resistant authentication strength.
Set the policy to Report-only, test it, and then move it to On.

Use FIDO2 security keys or certificate-based authentication where supported and appropriate. Password plus SMS is not phishing-resistant.

This layer matters because an attacker who controls an administrator account effectively controls your tenant. The account may be able to access mailboxes, SharePoint sites, Teams, security settings, and CUI repositories.

Layer 3: Block legacy authentication

Legacy protocols are a common source of avoidable exposure because they may bypass modern authentication and MFA.

Go to Entra ID > Protection > Conditional Access > Policies.
Select New policy.
Name it:

CA003 - Block legacy authentication - All users
Under Assignments > Users, select All users.
Under Target resources, select All cloud apps.
Under Conditions, select Client apps.
Enable the condition.
Select:
- Exchange ActiveSync clients
- Other clients
Under Access controls > Grant, select Block access.
Set the policy to Report-only.
Review sign-in logs and use the What If tool.
Set the policy to On after resolving legitimate dependencies.

Legacy protocols include older SMTP, IMAP, and POP3 patterns. They are especially dangerous when an organization believes that “MFA is enabled” but has not checked whether every authentication path uses modern authentication.

Layer 4: Require managed and compliant devices

MFA verifies the person. It does not prove that the device is safe.

Use Microsoft Intune to enroll and manage devices that access CUI.

Open the Microsoft Intune admin center.
Go to Devices.
Select Compliance policies.
Select Policies.
Select Create policy.
Choose the device platform.
Configure requirements such as:
- Device encryption
- Screen lock and password requirements
- Minimum operating system version
- Jailbreak or root detection for supported mobile platforms
- Device threat level, where integrated security capabilities support it
Assign the policy to the appropriate users or device groups.
Confirm that devices are reporting a compliance state.

Microsoft warns that devices without an assigned compliance policy may be treated as compliant unless the tenant-wide setting is changed. Review Endpoint security > Device compliance > Compliance policy settings and set Mark devices with no compliance policy assigned as to Not compliant when that matches your access plan.

Then create the Conditional Access policy:

Return to Entra ID > Protection > Conditional Access > Policies.
Select New policy.
Name it:

CA004 - Require compliant device - CUI applications
Under Users, select the users who can access CUI.
Under Target resources, select the relevant applications, such as SharePoint, OneDrive, Teams, and Exchange.
Under Grant, select Require device to be marked as compliant.
Test with a managed device, a noncompliant device, and an unmanaged personal device.
Enable the policy after testing.

This is the control that helps prevent CUI from landing on an unmanaged personal laptop.

3. Reduce administrative privilege and standing access

Many organizations configure MFA but leave too many people as Global Administrators. That defeats the purpose of least privilege.

Review roles at Entra ID > Roles and administrators. Export or record information that supports mapping your CUI boundary by identifying which systems and people are actually in scope:

The role.
Each assigned person or group.
Whether the assignment is permanent or eligible.
The business reason for the access.
The last review date.

As a practical rule, if your organization has more than a handful of Global Administrators, investigate why. Most administrators should have narrower roles.

Use Privileged Identity Management

Microsoft Entra Privileged Identity Management (PIM) provides eligible, time-limited administrative access instead of permanent standing access.

Open Entra ID.
Select Identity Governance.
Select Privileged Identity Management.
Select Microsoft Entra roles.
Select Roles.
Choose a privileged role.
Review current assignments.
Convert unnecessary permanent assignments to Eligible assignments.
Require activation with:
- MFA
- Justification
- A limited activation duration
- Approval for higher-risk roles
Configure notifications for activation and role changes.
Review the PIM audit history regularly.

Microsoft’s PIM documentation explains eligible assignments, just-in-time activation, approval, justification, and audit history.

Apply Conditional Access to the administrator population so PIM activation requires MFA and a compliant device. PIM is not a replacement for Conditional Access. It controls when a role becomes active; Conditional Access controls the conditions for access.

Separate everyday and administrative accounts

An administrator should have:

A normal account for email, meetings, and ordinary work.
A separate privileged account for administration.

Do not use the privileged account to read email, browse the web, or perform ordinary work.

Conditional Access governs cloud sign-ins. It does not govern every local privileged action on a workstation or server. Local administrative access requires additional controls, such as Windows Hello for Business, smart cards, or dedicated Privileged Access Workstations. Document this boundary in your System Security Plan.

Maintain emergency access accounts

Maintain a small number of emergency, or break-glass, accounts. Exclude them from standard Conditional Access policies so a policy mistake or service outage cannot lock every administrator out of the tenant.

Document:

The account purpose.
Who can use it.
Where credentials are stored.
The approval process.
The monitoring process.
The last test date.

Monitor every use. A break-glass account that is used should generate an investigation.

4. Tenant settings worth checking

MFA and Conditional Access are only part of the configuration. Review these settings deliberately.

Audit logging

Confirm that the unified audit log is enabled and retained long enough to meet your contractual and regulatory obligations. Check audit searches for:

Sign-ins.
Role assignments.
Policy changes.
File downloads.
Sharing changes.
Mailbox activity.

An event you cannot produce is difficult to defend during a review.

In the SharePoint admin center, review Policies > Sharing. Review OneDrive sharing separately. Decide whether CUI may be shared externally. If the answer is no, configure the tenant and sites to enforce that decision rather than relying on a policy statement.

Guest access and collaboration

Review:

Entra ID > External Identities > External collaboration settings
SharePoint and Teams guest settings
Cross-tenant access settings
Who can invite guests
What guests can access

Do not permit broad guest access simply because collaboration is convenient.

Mail flow and forwarding

In the Exchange admin center, review Mail flow > Rules. Consider rules that:

Block or quarantine messages containing sensitive content.
Prevent automatic forwarding to external addresses.
Alert on unusual forwarding behavior.
Route sensitive messages through approved review processes.

Mobile device management

Decide whether personal devices may access company data. Then enforce the answer through Intune, app protection, Conditional Access, or a documented prohibition. A policy that says “do not use personal devices” is not technical enforcement.

Session controls and alerts

Review Conditional Access Session controls for sign-in frequency and persistent browser sessions.

Configure alerts for:

Privileged role assignment.
New administrator activation.
Mass downloads.
Impossible-travel sign-ins.
New guest invitations.
Changes to Conditional Access policies.

Licensing affects which features are available, so record the licenses and dependencies in your configuration plan.

5. The evidence problem

Every configuration is a claim until you can show it.

For each policy or setting, retain:

The policy name.
A screenshot or export showing the setting.
The users, groups, applications, and exclusions in scope.
The date it was verified.
The tenant or system to which it applies.
The person who performed the review.
Any exceptions and their approval.

For CMMC Level 1 self-assessments, retain evidence for six years from the CMMC Status Date, subject to the requirements that apply to your contract and assessment type.

Configuration also drifts. A help-desk technician may change a sharing setting. An administrator may add a new Global Administrator. A licensing change may affect Intune or Conditional Access behavior.

Re-verify critical settings on a defined cadence and after material changes.

Technical Guide #9 will address the evidence process in more detail. The important point here is simple: a screenshot from the day before an assessment does not prove that the configuration remained effective for the entire period under review.

Current CMMC assessment timing does not eliminate the underlying work. Contractors may encounter pauses or delays affecting Phase II third-party assessment activity, but that should not be treated as relief from applicable DFARS 252.204-7012, contract requirements, NIST SP 800-171 practices, self-assessment, or your SPRS obligations. Verify the current contract language and official DoD notices. The official DFARS text and NIST SP 800-171 are better authorities than an informal summary.

6. Common Microsoft 365 mistakes and the fix

Relying on Security Defaults and calling it MFA: Create explicit Conditional Access policies with documented scope and enforcement.
Sharing one Global Administrator account: Create individual accounts so actions are attributable.
Leaving legacy authentication enabled: Use a report-only policy to find dependencies, then block Exchange ActiveSync and other legacy clients.
Leaving policies in report-only mode for months: Assign an owner, test date, decision date, and enforcement date to every policy.
Excluding the group that actually accesses CUI: Review policy coverage against your data flow and access groups.
Having no break-glass account: Create emergency accounts, store credentials according to policy, and monitor their use.
Using administrator accounts for email and browsing: Separate privileged and everyday accounts.
Changing settings after the assessment without re-evidence: Capture new evidence whenever a setting changes, then update the verification date.

7. Printable Microsoft 365 compliance configuration checklist

Confirm whether the tenant is Commercial, GCC, or GCC High, and document the endpoint, contract requirements, and data scope.
Identify where CUI is stored, processed, and transmitted before selecting or changing the platform.
Create and enforce a Conditional Access policy requiring MFA for all users and all cloud applications.
Create a separate policy requiring phishing-resistant authentication for privileged roles.
Create and enforce a policy blocking Exchange ActiveSync and other legacy authentication clients.
Enroll in-scope devices in Intune and require encryption, screen lock, supported OS versions, and applicable threat protections.
Require compliant devices for SharePoint, OneDrive, Teams, Exchange, and other applications that hold CUI.
Review Global Administrator and other privileged role assignments; convert unnecessary standing access to PIM-eligible access.
Require MFA, justification, approval where appropriate, and a compliant device for PIM activation.
Configure external sharing, guest access, mail flow, forwarding, mobile access, and session controls deliberately.
Create and test break-glass accounts, audit logging, privileged-role alerts, mass-download alerts, and impossible-travel alerts.
Capture evidence for every configuration, assign a re-verification cadence, and re-evidence every material change.

Sources

Final note: configure first, prove continuously

Tenant configuration is the easy part. Proving it stayed configured month after month is what consumes the time. Complynt is an enterprise compliance automation platform for control mapping, evidence collection, continuous monitoring, pre-built content packs, and policy-as-code across more than 150 frameworks, including CMMC, NIST SP 800-171, NIST SP 800-53, RMF, SOC 2, HIPAA, and ISO 27001. It runs on FedRAMP High and DoD IL5 authorized infrastructure on Palantir’s federal cloud. H&V is EDWOSB certified. H&V does not issue certification and cannot guarantee any assessment outcome; the right sequence is audit first, plan second, and tools third. You can request a free compliance readiness check or learn more at hvfsusa.com.