Architecting a DoD-Compliant (CMMC 2.0) Microsoft 365 and SharePoint (On-Prem) Environment

Picture this: you’ve just landed a gig to architect a Microsoft 365 tenant with SharePoint on-prem and cloud for a DoD environment. You’re staring down at a fresh copy of NIST 800-53 (R5), a massive 500-page tome of standard policies, guidelines, and verbose technical requirements covering a full spectrum of security roles. Like Frank Herbert’s Dune in both size and complexity, it presents a challenging landscape for even experienced security professionals to navigate. To make matters worse, these guidelines are intentionally generalized to fit countless different environments.

You must be savvy enough to translate this dense book of technical terminology into practical requirements for your specific environment when gathering requirements, conducting audits, or building solutions for DoD environments and corporations seeking to avoid becoming the next breach headline. This remains challenging even for veteran security oriented developers and administrators as technology evolves rapidly. Finding clear, actionable guidance in NIST can feel as difficult as locating water in the deserts of Arrakis. Technology moves faster than a sandworm and this is where your PL-400/600 shines, you need to nail NIST 800-53B (Moderate) and NIST 800-171 Rev. 3 baselines for CMMC 2.0 Level 2 before your environment goes live.

🏜️Here’s how to conquer the desert without losing your mind.

Download the 12 week Sprint Plan: Grab our GCC High Compatible 12 Week Sprint Plan for a step-by-step roadmap with evidence collection.

12-Week Sprint Plan: Microsoft 365 Tenant and SharePoint Stand-Up for CMMC 2.0 Level 2

Wait, Is it really possible to stand up a O365/On-Prem environment in 12 weeks?

As a veteran developer I’ve helped stand up SharePoint environments for DoD environments. Securing an Authority to Operate (ATO) for a Microsoft 365 tenant with SharePoint (on-premises and cloud), targeting Cybersecurity Maturity Model Certification (CMMC) 2.0 Level 2, takes 6 to 18 months. A well-prepared team can hit 9 to 12 months, covering Department of Defense (DoD) Risk Management Framework (RMF) steps, implementation, assessment, and Authorizing Official (AO) approval. You want your portion of the process to be frictionless to reduce that timeline.

Implementation sprint plan (12 to 16 weeks)

A 12-week sprint plan, with a 2 to 4 week buffer, prepares the environment for pre-assessment. This assumes:

  • Licenses, network access, and procurement are complete.
  • Roles and decision-makers are defined and available for reviews.
  • Stakeholders are engaged for user acceptance testing and approvals.

The plan configures SharePoint, Power Platform, and Entra ID to meet NIST 800-171 Rev. 3 controls and collects audit evidence. The buffer handles delays in approvals, testing feedback, or fixing gaps (like missing encryption). Total time: 12 to 16 weeks (3 to 4 months).

Full ATO process

The ATO process extends beyond implementation due to RMF and AO requirements:

  • Implementation and evidence collection (3 to 4 months): The 12 to 16 week sprint sets up the system and documents compliance.
  • Assessment and remediation (2 to 4 months): Tests (e.g., Azure Policy scans) identify gaps. Fixing issues, like enabling MFA, depends on complexity.
  • AO review and approval (2 to 6 months): The RMF package (System Security Plan, Security Assessment Report, Plan of Action and Milestones) goes to the AO. Review time depends on their workload and submission quality.

Total: 7 to 14 months, with 9 to 12 months typical. Simple systems might take 6 to 9 months; delays in approvals or resources can stretch to 18.

Factors affecting timeline

  • Complex systems: Hybrid setups with legacy apps add integration challenges.
  • Unprepared teams: Without procurement or roles ready, add 2 to 6 months.
  • Gaps: Issues like missing audit logs can add 1 to 3 months for fixes.
  • AO variability: DoD agencies (e.g., DISA, Navy) have different review speeds.
  • eMASS access: Cleared contractors with eMASS move faster; manual workflows slow things down.

Staying on track

  • Run the sprint plan with parallel tracks (identity, SharePoint) and document controls early.
  • Talk to the AO in the Prepare and Categorize steps to avoid rework.
  • Automate compliance with Azure Policy, Purview, and Defender for Cloud.
  • Budget 1 to 2 months extra beyond the buffer for surprises.

Check with your Information Security Officer or a CMMC consultant, and review DoD RMF and NIST 800-171 Rev. 3 guidelines for specifics.

Note: This is not legal advise, simply my personal approach to implementing Cybersecurity Maturity Model Certification (CMMC) Level 2 requirements based on my experience and understanding of the framework. It is intended for informational purposes only and does not constitute professional consulting advice or a definitive guide to achieving CMMC compliance.

Assumptions and Success Criteria

Assumptions

  • Licenses, network access, and procurement are complete
  • Roles and decision-makers are identified and available for timely reviews
  • Target impact level Moderate with CUI in scope and enclave decision documented (GCC High vs Commercial)
  • Parallel tracks for identity, SPO, Power Platform, and security tooling are staffed

Success Criteria

  • Timebox: 12 weeks with a 2–4 week buffer for approvals and remediation
  • Evidence captured for each implemented control and archived in Records
  • Gaps logged with owners, priorities, and due dates
  • UAT completed with critical issues remediated
  • RMF package (SSP and POA&M) prepared for AO pre‑assessment review

How Do You Proceed?

Bad News First

I’m a rip-off-the-band-aid kind of guy, so here’s the tough stuff:

Brew 2-3 cups of coffee and carve out a morning to slog through NIST 800-53’s intro and first three chapters (up to “3.13 PROGRAM MANAGEMENT”). It’s about 130 pages of dense jargon, but it’s your map to DoD security expectations. Keep those eyelids open, you won’t be able to recall everything on command but you will enrich yourself and be ready to discuss these complex topics.

Good News

You don’t have to implement every single control in NIST 800-53 or 800-171 Rev. 3. These frameworks are flexible, letting you tailor controls to your environment’s Moderate risk profile for CUI. As a Power Apps developer or SharePoint admin, your job is to lock down your systems, document how they fit into the broader security setup, and sync up with your IT security team to avoid stepping on toes. You have deadlines, so you need to focus on your lane.

Key Control Families for SharePoint and Power Apps

For CMMC 2.0 Level 2, you’re targeting NIST 800-171 Rev. 3’s 97 consolidated controls. These are the heavy hitters for SharePoint and Power Apps:

  • Access Control (AC): Lock down access to the bare minimum for users and service accounts. Require MFA and check permissions regularly (3.1.1, 3.1.5).
  • Identification and Authentication (IA): Enforce strong passwords and MFA for everyone, managed through Entra ID (3.5.1, 3.5.7).
  • Audit and Accountability (AU): Log every move: user actions, config changes, data access in SharePoint and Power Platform. Keep those logs safe for auditors (3.3.1, 3.3.5).
  • System and Communications Protection (SC): Encrypt data at rest (SharePoint libraries, Power Apps data) and in transit (TLS 1.3, HTTPS). Secure your sites and apps like a fortress (3.13.1, 3.13.5).
  • System and Information Integrity (SI): Watch for sketchy behavior (like bulk downloads) and stay on top of patches as best as you can for on-prem (3.14.1, 3.14.2).
  • System and Services Acquisition (SA): Bake security into your Power Apps and SharePoint solutions with secure coding and testing (3.4.7).

These controls are straight from NIST 800-171 Rev. 3, ensuring you’re ready for a CMMC 2.0 Level 2 assessment.

Configuration Examples for Compliance

Here’s how to lock down SharePoint and Power Apps to meet NIST 800-171 Rev. 3 for CMMC 2.0 Level 2. These configs are your architectural glue:

  • Power Platform DLP Policies: Block risky connectors (e.g., HTTP, SQL) in non-prod environments. Keep business data in approved connectors (NIST 800-171 Rev. 3 3.13.2, 3.4.7).
Step-by-Step
  • Open the Power Platform Admin Center at https://admin.powerplatform.microsoft.com and navigate to Data policies under Resources.
  • Click + New policy and name it something specific like “Tenant Baseline DLP Policy”.
  • In the Connectors tab, sort built-in connectors into three groups:
    • Business: Internal systems (SharePoint, SQL Server, Dataverse, OneDrive for Business)
    • Non-Business: External consumer services (Gmail, Dropbox, Twitter)
    • Blocked: High-risk connectors (HTTP, unapproved third-party APIs)
    • For the SQL Server connector, click Configure then Connector actions to restrict operations. Allow Read but block Insert, Update, and Delete to enforce read-only access.
    • For HTTP, HTTP with Azure AD, SQL, Azure Blob Storage, use Endpoint filtering to whitelist specific domains or IP addresses (like https://api.yourcompany.com) and block everything else.
    • In the Custom connectors tab, set default behavior to Blocked. Only allow approved endpoints using pattern matching (such as .yourcompany.com).
    • In the Scope tab, decide whether the policy applies across the entire tenant or excludes specific environments (you might exclude Dev/Test if you’re using separate policies there).
    • Set the Default group for new connectors to Blocked rather than Non-Business. This prevents unknown connectors from being used automatically.
    • Review and Save the policy. It takes effect immediately for all scoped environments.
    • For Dev/Test environments, create a separate DLP policy with stricter rules (block HTTP entirely, for example) and apply it only to those environments.
    • Monitor violations in the Power Platform Admin Center under Data policies then Policy violations, or integrate with Microsoft Defender for Cloud Apps for advanced threat detection and audit logging.

The most restrictive policy applies when multiple policies are assigned. Environment-level policies cannot override tenant-level ones.

  • Environment Strategy: Split Dev, Test, and Prod environments. Lock down Prod by disabling maker permissions and using managed solutions (NIST 800-171 Rev. 3 3.4.1, 3.4.7).
  • Conditional Access and PIM: Require MFA for Power Apps, Power Automate, and SharePoint Online. Use Entra ID PIM for just-in-time admin access with approval (NIST 800-171 Rev. 3 3.5.1, 3.1.5).
Step-by-Step

1. Enable MFA via Conditional Access

  • Go to Microsoft Entra Admin CenterProtectionConditional Access.
  • Create a new policy:
    • Name: “Require MFA for Power Platform & SharePoint”
    • Users: Select relevant users or groups
    • Cloud apps: Include Power Apps, Power Automate, SharePoint Online
    • Conditions: Apply as needed (device state, location)
    • Access controlsGrant: Require multi-factor authentication
  • Enable the policy to enforce MFA at sign-in.

2. Configure PIM for just-in-time admin access

  • In Microsoft Entra ID, go to Privileged Identity Management (PIM).
  • Assign users as eligible for admin roles (Global Administrator, SharePoint Administrator).
  • Configure role settings:
    • Assignment Type: Eligible
    • Duration: Set time limits (max 8 hours)
    • MFA: Require during activation
    • Approval: Enable and specify approvers
    • Justification: Require business reason
  • Users must activate roles via PIM when needed, fulfilling MFA and approval requirements.
  • Data Protection: Store Power Apps secrets in Azure Key Vault and apply sensitivity labels to SharePoint libraries with CUI (NIST 800-171 Rev. 3 3.13.1).
  • SharePoint Site Configuration: Set CUI sites to private or org-only, ban anonymous links, and enforce desktop app access for encrypted files. Keep 100 major versions (NIST 800-171 Rev. 3 3.1.20, 3.3.1).
  • Auditing and Alerting: Fire up Purview Audit (Premium) and Unified Audit Logs. Send Power Platform analytics to Sentinel and alert on risky moves like “Anyone” links (NIST 800-171 Rev. 3 3.3.1, 3.6.2).
  • Least Privilege Access: Use Entra ID or M365 Groups for permissions, avoiding direct user assignments except for site admins. In Dataverse, use business units and role-based security (NIST 800-171 Rev. 3 3.1.1).

    Tip: Use PnP PowerShell to create a report showing group-based access.
Connect-PnPOnline -Url https://yourtenant.sharepoint.com -UseWebLogin
Get-PnPSitePermission | Export-Csv -Path "SitePermissions.csv"
  • Secure Automation: In Power Automate, use solution flows with service principals and require approvals for premium connectors (NIST 800-171 Rev. 3 3.4.7, 3.13.2).
  • Deployment Pipeline: Wrap all apps, Dataverse tables, and flows into solutions. Export unmanaged from Dev, test in Test, and import managed to Prod via Power Platform Pipelines or Azure DevOps. Use PnP templates for SharePoint sites (NIST 800-171 Rev. 3 3.4.1, 3.12.1).
Example PnP JSON
{
"schema": "https://developer.microsoft.com/json-schemas/sp/sites/provisioning-schema.json",
"templateName": "Contoso Site Template",
"description": "Standard site for Contoso teams with document library and news",
"siteDesignId": "6142d2a0-63a5-4ba0-aede-d9fefca2c767",
"webUrl": "team",
"title": "Team Site",
"shareByEmailEnabled": false,
"siteScripts": [
{
"title": "Add Document Library",
"description": "Adds a standard document library",
"content": "function() { var ctx = SP.ClientContext.get_current(); var web = ctx.get_web(); var listInfo = new SP.ListCreationInformation(); listInfo.set_title('Documents'); listInfo.set_templateType(SP.ListTemplateType.documentLibrary); web.get_lists().add(listInfo); ctx.load(listInfo); ctx.executeQueryAsync(); }"
}
],
"lists": [
{
"title": "Shared Documents",
"url": "Shared Documents",
"template": 101,
"sublists": [],
"permissions": {
"breakRoleInheritance": true,
"copyRoleAssignments": false,
"roleAssignments": [
{
"principal": "Contoso Members",
"roleDefinition": "Edit"
},
{
"principal": "Contoso Owners",
"roleDefinition": "Full Control"
}
]
}
}
],
"theme": "Contoso Theme",
"homePage": {
"sections": [
{
"columns": [
{
"colSize": 12,
"controls": [
{
"id": "1dafb215-9a52-47ed-95cb-74391994955b",
"data": {
"title": "Welcome",
"description": "Welcome to the team site"
}
}
]
}
]
}
]
}
}

On-Premises vs. Cloud: Key Differences

  • Identity and Access:

On-Prem (Commercial Environments without CAC):
Rely on AD DS, ADFS, and Kerberos/NTLM for authentication. Enforce MFA using Entra ID Conditional Access with hybrid Entra ID join, which extends cloud-based MFA and device compliance policies to on-prem apps. This closes the MFA gap for internal resources.

Caveat: Without CAC, MFA must be enforced at the application or proxy level (e.g., via ADFS + Entra MFA server, or Conditional Access for hybrid-joined devices). Service accounts and legacy apps may require exclusions or modernization.


Cloud:
Use Entra ID, Conditional Access, MFA, and PIM for privileged access. Govern guest access with Entitlement Management to meet NIST 800-171 Rev. 3 3.1.20.

  • Network and Perimeter:
    • On-Prem: You own firewalls, proxies, and TLS termination. Document data flows and ports (NIST 800-171 Rev. 3 3.13.5, 3.4.1).
    • Cloud: Go Zero Trust with Private Endpoints and Defender for Cloud Apps (NIST 800-171 Rev. 3 3.13.5).
  • Patching and Configuration Drift:
    • On-Prem: Patch with WSUS/SCCM and use PnP provisioning to keep configs tight (NIST 800-171 Rev. 3 3.4.1).
    • Cloud: Evergreen services with Azure Policy and Power Platform DLP to stop misconfigs (NIST 800-171 Rev. 3 3.4.7).
  • Data Residency and Encryption:
    • On-Prem: Manage HSMs, SQL TDE, BitLocker, and backups. (NIST 800-171 Rev. 3 3.13.1).
    • Cloud: Roll with Microsoft’s AES-256 encryption or Customer Key via Azure Key Vault (NIST 800-171 Rev. 3 3.13.1).

Caveat: Federal agencies must ensure encryption solutions comply with FIPS 140-2 Level 3 (or higher). On-prem, use FIPS-validated HSMs, SQL TDE with approved modules, and BitLocker in FIPS mode (with recovery passwords disabled or FIPS-compliant protectors).

In cloud, use Azure Government with Customer Key and Azure Managed HSM (FIPS 140-2 Level 3 validated) to maintain control and compliance. Standard AES-256 encryption alone may not suffice without validated modules and proper key management.

  • Logging and Investigations:
    • On-Prem: Centralize ULS, Windows Event, and SQL logs in a SIEM (NIST 800-171 Rev. 3 3.3.1).
    • Cloud: Stream Purview Audit, Entra logs, and Power Platform analytics to Sentinel (NIST 800-171 Rev. 3 3.3.1).
  • Change Control:
    • On-Prem: Get CAB approvals and check changes with health analyzer (NIST 800-171 Rev. 3 3.4.5).
    • Cloud: Use pipelines and policy exemptions with expiry (NIST 800-171 Rev. 3 3.4.5).

Integrate the DoD RMF

The DoD Risk Management Framework sets the lane markers for earning an Authority to Operate. It drives every configuration, architecture choice, and page of documentation when you stand up a tenant, and it’s the process your audit will probe. To keep the grind manageable, use the Enterprise Mission Assurance Support Service (eMASS), a DoD web tool that centralizes control documentation, artifact handling (System Security Plan, Security Assessment Report, POA&M), risk assessments, and reciprocity for inheritable controls—reducing manual churn and keeping compliance traceable end to end. Access is limited to federal personnel and cleared contractors with CAC or ECA credentials; if you’re outside that group, plan on alternative tooling or disciplined manual workflows that mirror the same artifacts and checkpoints.

Here’s the 7-step playbook:

  1. Prepare: Establish roles, scope, and priorities
  2. Categorize: Tag your system as Moderate for CUI and document in the System Security Plan (SSP).
  3. Select: Pick NIST 800-171 Rev. 3 controls, tailored with DoD SRG IL4/IL5 overlays.
  4. Implement: Lock in SharePoint and Power Apps configs, documenting every setting.
  5. Assess: Run Azure Policy checks and technical tests; gather evidence at every step.
  6. Authorize: Prep an AO package with SSP, Security Assessment Report (SAR), and Plan of Action and Milestones (POA&M).
  7. Monitor: Run weekly policy scans, monthly control reviews, and quarterly access checks; keep the POA&M fresh.

RMF Artifacts:

  • SSP: Store in a version-controlled repo, detailing your system boundary and controls.
  • SAP/SAR: Map assessor tests to evidence from Azure Policy and Purview.
  • POA&M: Track gaps with control ID, description, risk rating, milestones, and due dates.

Roles:

  • AO: Green-lights ATO/IATO and owns risks.
  • SCA: Runs assessments and writes the SAR.
  • ISSM/ISSO: Manages the security program and monitoring.
  • System Owner/DevOps: Builds controls and collects evidence.

Continuous Monitoring: Track KPIs (e.g., compliance score, DLP violations) and automate reports with Defender for Cloud and Sentinel.

DoD Standards and NIST 800-171 Rev. 3

If you’re handling CUI for the DoD, NIST 800-171 Rev. 3’s 97 controls are non-negotiable for CMMC 2.0 Level 2 compliance, like showing up to formation on time (unless you’re the chief). Non-DoD folks without CUI can stick to NIST 800-53 controls tailored to their risk profile. To nail 800-171 Rev. 3:

  1. Discover and Classify Data:
    • Solution: Use Microsoft Purview to slap “CUI” sensitivity labels on data with encryption and access restrictions. Auto-classify with keyword patterns or machine learning. Scan on-prem shares and SharePoint (NIST 800-171 Rev. 3 3.13.1).
    • Evidence: Purview label policy export showing CUI settings.
  2. Map Permissions:
    • Solution: Run PnP PowerShell to audit SharePoint and Power Platform permissions. Stick to group-based access and visualize in Power BI (NIST 800-171 Rev. 3 3.1.1).
    • Evidence: PowerShell permission report CSV.
  3. Leverage Cloud Tools:
    • Solution: Use Azure Policy for CMMC 2.0 initiatives (e.g., no remote debugging, no privileged containers). Monitor with Defender for Cloud’s compliance dashboard (NIST 800-171 Rev. 3 3.12.1).
    • Evidence: Azure Policy report and Defender dashboard export.
  4. Implement Continuous Monitoring:
    • Solution: Catch config drift (e.g., disabled SQL auditing) with Defender for Cloud. Set alerts and auto-remediation via Azure Policy’s DeployIfNotExists (NIST 800-171 Rev. 3 3.4.1, 3.14.2).
    • Evidence: Sentinel alert logs and remediation history.

How to Talk Security to Your Manager

Something like:

“Hey, we’ve got to lock down this environment for CMMC 2.0 Level 2 to keep CUI safe.
These are our shields against adversaries who’d love to spice up their day with our data.
I’ve mapped them to Microsoft tools we already have, so no budget surprises.
I need your go-ahead to roll this out.”

These controls align with NIST 800-171 Rev. 3’s 97 requirements for CMMC 2.0 Level 2 compliance:

  1. Access Control (3.1.1): Limit access with Entra ID PIM for JIT admin roles.
  2. Awareness and Training (3.2.1): Push CUI training via Microsoft Viva Learning.
  3. Audit and Accountability (3.3.1): Log everything with Purview Audit (Premium).
  4. Configuration Management (3.4.1): Enforce device settings with Intune.
  5. Identification and Authentication (3.5.1): Require MFA via Entra Conditional Access.
  6. Incident Response (3.6.2): Test playbooks with Microsoft Sentinel.
  7. Maintenance (3.7.1): Automate updates with Intune.
  8. Media Protection (3.8.4): Sanitize exports with Purview eDiscovery.
  9. Personnel Security (3.9.1): Enforce NDAs with Purview and Power Automate.
  10. Physical Protection (3.10.1): Restrict VM locations with Azure Policy.
  11. Risk Assessment (3.11.2): Scan vulnerabilities with Defender Vulnerability Management.
  12. Security Assessment (3.12.1): Check controls with Defender for Cloud.
  13. System and Communications Protection (3.13.1): Encrypt CUI with Purview labels.
  14. System and Information Integrity (3.14.2): Spot threats with Defender for Endpoint.

Download the sprint plan for free here

Glossary

  • Entra ID: Microsoft’s cloud identity platform (formerly Azure AD); source for MFA, Conditional Access, PIM
  • PIM (Privileged Identity Management): Just‑in‑time admin activation with approval and audit
  • Conditional Access: Policy engine enforcing signals like MFA, device compliance, and session controls
  • CAE (Continuous Access Evaluation): Real‑time reevaluation of sessions when risk changes
  • Purview: Compliance suite for labels, eDiscovery, DLP, and audit
  • Defender for Cloud: Cloud security posture management and regulatory compliance dashboards
  • Defender for Office 365: Email and collaboration threat protection
  • Sentinel: Cloud‑native SIEM/SOAR for analytics, hunting, and playbooks
  • Intune: Device compliance and configuration management
  • Customer Key: Customer‑managed encryption key option for M365
  • CUI (Controlled Unclassified Information): DoD‑sensitive data in scope for 800‑171
  • GCC High: US sovereign cloud for certain US government workloads
  • DFARS 252.204‑7012: DoD contract clause requiring incident reporting and adequate security for CUI
  • DoD SRG IL4/IL5: DoD Impact Levels used for cloud authorization overlays
  • DISA STIGs: DoD hardening guides for platforms and services
  • RMF (Risk Management Framework): DoD lifecycle for ATO
  • SSP (System Security Plan): Boundary and control implementation blueprint
  • SAR (Security Assessment Report): Assessor results mapped to controls
  • POA&M (Plan of Action & Milestones): Gap tracking with remediation plan
  • DLP (Data Loss Prevention): Policies to prevent improper data sharing or exfiltration
  • Dataverse: Power Platform data platform with role‑based security
  • PnP.PowerShell: Automation module for SharePoint administration and provisioning

Citations and References

Legal Disclaimer

This journal reflects my personal approach to implementing Cybersecurity Maturity Model Certification (CMMC) Level 2 requirements based on my experience and understanding of the framework. It is intended for informational purposes only and does not constitute professional consulting advice or a definitive guide to achieving CMMC compliance. Every organization’s environment is unique, and compliance requirements may vary based on specific circumstances, systems, and regulatory obligations.

Readers are strongly encouraged to consult with their organization’s Information Security Officer, qualified cybersecurity professionals, or legal counsel to develop a tailored compliance strategy. Always conduct your own research and refer to official sources, such as NIST 800-171 Rev. 3 and DoD guidelines, to ensure adherence to applicable standards. The author and publisher are not responsible for any actions taken based on the information provided in this post.