Public Sector Blog

10 MIN READ

Lessons Learned from CMMC: A Q&A with IT Professionals

Microsoft

Jun 12, 2025

The Cybersecurity Maturity Model Certification (CMMC) program is designed to ensure that United States Department of Defense (DoD) contractors and subcontractors implement adequate cybersecurity measures to protect Federal Contract Information (FCI) and Controlled Unclassified Information (CUI) within their unclassified networks.  

The program establishes a consistent pre-award assessment methodology to verify that contractors have implemented necessary cybersecurity protections. CMMC requirements apply to all DoD solicitations and contracts where contractors process, store, or transmit FCI or CUI. The certification process involves different levels of cybersecurity, which will be determined as part of each contract or at the program level. Compliance with CMMC is mandatory for contract awards once the Title 48 of the Code of Federal Regulations (48 CFR) rule is published. As a result contractors must undergo either self-assessments or third-party assessments depending on the level specified in the contract.

In this blog, we dive into the lessons learned from achieving CMMC compliance, structured as a Q&A session. In this session, Justin Orcutt interviews Shawn Anderson and Evan Cottingham from Microsoft’s Mixed Reality Division to share their insights and experiences with their recent CMMC Certification.

The Mixed Reality Division at Microsoft recently received a 110 on their CMMC assessment. When their initial contract started with the government CMMC was not a public requirement. Throughout the delivery of one of the programs it became clear that CUI will be the designation moving forward and achieving CMMC will be the minimum baseline for security. The team realized the importance of leading with compliance so they set off to architect an environment that could be compliant with existing requirements, Defense Federal Acquisition Regulation Supplement (DFARS) 252.204-7012, while keeping future requirements for, CMMC, top of mind.

Mixed Reality’s program is unique in the fact that it included digital and physical scope and covered everything from engineering and manufacturing tools to telemetry to interconnections with other systems.

Meet the Experts

Justin Orcutt
Microsoft, Director of Cybersecurity
View LinkedIn Profile
Shawn Anderson
Microsoft, CISO & Director of Program Protection & Compliance, Mixed Reality
View LinkedIn Profile
Evan Cottingham
First Information Technology Services (FITS), GRC Program Manager, Mixed Reality
View LinkedIn Profile

Q&A Session

Justin:

Shawn, can you tell me a little bit about your team and when CMMC first become part of your focus?

Shawn:

In November 2018, Microsoft was awarded an Other Transaction Authority (OTA) agreement for the rapid prototyping and development of the Integrated Visual Augmentation System (IVAS), leveraging our existing HoloLens 2 technology. Initially, the program’s security requirements were classified as For Official Use Only (FOUO). However, subsequent modifications to the agreement introduced the requirement to comply with DFARS 252.204-7012, Safeguarding Covered Defense Information and Cyber Incident Reporting, as the DoD designated most program data as CUI.

At the outset, Microsoft did not yet have an environment capable of supporting office automation, engineering, and manufacturing at the CUI level. Consequently, we built a compliant environment from the ground up—integrating engineering and manufacturing tools, telemetry from manufacturing devices, and dashboards for customer access.

To ensure compliance with DFARS 7012 and maintain the trust of our government customers, I initiated annual independent third-party audits of our environment. Additionally, government auditors conducted regular assessments. While not explicitly required under DFARS 7012, we welcomed these audits as opportunities to strengthen our security posture.

Having closely followed the development of the CMMC since its inception, I anticipated a surge in demand for certification once the final rule took effect. In early 2022, I began discussions with Logan Shim (then our GRC Program Manager) about proactively preparing for CMMC. Following a perfect score on a government audit in February 2024, we decided to formally pursue certification—despite the final rule not yet being in effect.

This early investment positioned us exceptionally well. As a result, we were able to successfully complete the audit and obtain our CMMC Level 2 certification shortly after the final rule was enacted on December 26, 2024.

Justin: 

Evan, how long have you been working on this project, and when did the CMMC efforts really start?

Evan:

 I joined in late 2021. The CMMC efforts really started taking off in 2022 when we began with the NIST 800-171 work, getting ready for our self-assessment phase, and it evolved from there. (Special thanks to our old colleague, Logan Shim for spearheading a lot of the initial NIST 800-171 and CMMC efforts.)

Justin:  

Shawn, what were some of the challenges you faced in understanding the scope of your environment?

Shawn: 

One of the most significant challenges we encountered was achieving full visibility into our environment. In fast-paced engineering contexts, rapid innovation often takes precedence over documentation, which can lead to blind spots in system architecture and data flows.

To mitigate this, we adopted a closed and tightly controlled approach when building our secure environment, ensuring a strong security posture from the outset. This was critical not only for internal assurance but also to meet the rigorous compliance requirements of the Department of State (ITAR), Department of Commerce, and Department of Defense (DFARS/CUI). Ensuring that our facilities, systems, and operational processes adhered to these standards was foundational to supporting sensitive government programs and protecting CUI and ITAR export-controlled data.

Justin: How did you handle documentation and ensure it was in the correct language for CMMC assessments?

Shawn: 

We had maintained a System Security Plan (SSP) for several years, but aligning it with CMMC standards required a significant shift in both language and structure. One of the more interesting challenges was adapting our documentation to reflect the terminology, formatting, and expectations outlined in the CMMC framework.

This meant more than just updating content—it required us to reframe how we described our controls, processes, and evidence. We had to adopt a more formalized lexicon that aligned with NIST 800-171 and CMMC-specific language, ensuring clarity and traceability for assessors. It was a valuable exercise that not only improved our audit readiness but also enhanced the overall maturity and consistency of our documentation practices.

Justin: Shawn, can you tell me about the Compliance Copilot you built and its purpose?

Shawn: 

To support our engineering teams in navigating complex regulatory requirements, we developed and deployed a Compliance Copilot—a contextual, in-environment assistant designed to help identify and properly handle CUI.

The Compliance Copilot acts as a real-time guide embedded within our secure workflows. It provides engineers with clear, actionable guidance on:

Whether specific data or artifacts qualify as CUI,
How to properly label, store, and transmit that information,
What access controls apply based on classification,
And how to remain compliant with export control regulations, including ITAR, EAR, and DFARS 7012.

What made this initiative particularly impactful was its ability to translate regulatory language into engineering-friendly terms, reducing friction and uncertainty. Rather than relying on static documentation, the Copilot delivers just-in-time compliance insights, helping teams make informed decisions without slowing down development.

This tool has been instrumental in raising awareness, reducing compliance risk, and embedding a culture of security and accountability across our engineering organization.

Justin: What advice would you give to companies just starting their CMMC journey?

Shawn: 

Begin by understanding the purpose behind CMMC. It is not just a compliance checkbox, but a framework for protecting sensitive information and building long-term trust with government partners. Having a clear sense of why you're pursuing certification will help guide your decisions and priorities.

Next, take the time to thoroughly understand your environment. Many organizations discover that their systems, data flows, and responsibilities are more fragmented than they realized. You need a clear picture of what you have before you can secure it.

It is also essential to foster strong collaboration between IT, security, and engineering teams. CMMC compliance is not just a security initiative—it requires shared ownership and active participation across disciplines. Involve engineering teams early in the process so they understand how their work contributes to compliance goals.

Finally, prioritize documentation from the beginning. Use the CMMC framework and terminology to structure your materials so they are audit-ready. Good documentation supports not only compliance but also operational clarity and continuous improvement.

Justin: Many companies struggle to understand that their software might be in scope for CMMC. Can you elaborate on this?

Shawn: 

Many don’t realize that if they’re building products for the military, especially those subject to ITAR or EAR 600, the associated software is also considered CUI.

For example, if you're developing a scope for a military rifle, that scope is likely ITAR export-controlled. If so, then any software or driver that supports it is likely ITAR too, and considered CUI. That means that you need to protect this data within a CMMC compliant environment.

Justin: Can you give an example of software components that might be considered CUI?

Shawn: 

Certainly. Consider a company developing flight control software for a military drone. The drone itself is likely ITAR export-controlled, and any software that controls navigation, targeting, or telemetry would also be considered CUI.

Beyond the core code, supporting materials like source code repositories, simulation data, performance test results, and system architecture diagrams can also fall under CUI. Even if the software is modular or reused across platforms, if it supports an export-controlled system, it must be treated accordingly.

This is why it's critical for engineering teams to understand how their work connects to export controls. We’ve addressed this by building tools like our Compliance Copilot, which helps teams identify and handle CUI appropriately throughout the development lifecycle.

Justin: Evan, how did you ensure that your software was compliant with CMMC requirements?

Evan:

 For software used within our product, our Mixed Reality Information Security team implemented a robust program-specific software review process that supplements the Microsoft Corporate Software Governance process. This process includes a threat model review in which all data flows and dependencies are analyzed as well as testing and analysis of the software within an isolated sandbox.

For software developed within this environment for the end-product, the Mixed Reality Information Security team partnered with our Product Security team to ensure software is developed in accordance with the Microsoft Security Development Lifecycle (SDL) and in compliance with our program-specific Security Classification Guide (SCG).

The "Compliance Copilot" that we built using Azure AI Foundry really helped here. Through connecting the Compliance Copilot with a Knowledge Base of all our program policies, procedures, and standards, it provided specific and consistent guidance regarding our software governance processes ensuring that teams were aligned on these requirements.

Justin: Shawn, what was the hardest control for you to meet?

Shawn: 

One of the most challenging aspects was aligning our SSP and supporting documentation with the CMMC format and expectations. We had maintained an SSP for years, but CMMC required a shift—not just in structure, but in how we described our controls.

We had to rework the language, terminology, and presentation to match the CMMC lexicon. This meant translating our existing documentation into a format that clearly mapped to NIST 800-171 requirements and could stand up to audit scrutiny. It was a valuable exercise, but also a complex one, because it required close coordination across teams and a deep understanding of how each control was implemented in practice.

Justin: Evan, what was the hardest control for you to meet?

Evan: 

The physical security controls were uniquely challenging for us. We had to account for lab spaces and our manufacturing environment across multiple campuses and states, ensuring all access to physical spaces was properly documented and tied to our tenting process.

This also required a lot of coordination across our Program Protection team, IT team, Lab Owners, Manufacturing Environment personnel, and Global Security to ensure alignment during the on-site portion of our CMMC assessment when the majority of our physical and personnel security controls were assessed in-person.

Justin: What advice would you give to companies just starting their CMMC journey?

Shawn: 

Start by understanding the purpose behind CMMC. It’s not just about passing an audit—it’s about protecting sensitive data and building a culture of accountability across your organization

Take time to truly understand your environment. You need a clear picture of your systems, data flows, and responsibilities before you can secure them. Strong documentation from the beginning, aligned to CMMC standards, will save time and reduce friction later.

Most importantly, recognize that CMMC is a team effort. Success depends on leadership buy-in and tight collaboration across departments. If it weren’t for the strong partnership between our compliance, engineering, IT, Manufacturing Systems IT, and federal teams, we wouldn’t have been able to achieve what we did. These groups must work together from day one, with shared ownership and a clear understanding of their role in the compliance journey.

Summary and Takeaways

From this insightful discussion, here are four tangible takeaways for IT professionals:

Thoroughly Assess Your Environment: Understand that your manufacturing floor, physical buildings, specialized machinery, and software might be in scope. Ensure every component that stores, processes, or transmits CUI is identified and included in your scope.
Document Early and Accurately: Start documenting all policies, procedures, and controls early. Ensure that your documentation is aligned with CMMC requirements to save time and effort during the audit process.
Foster Collaboration Across Teams: Engage all relevant teams, including engineering, IT, and compliance, from the beginning. Ensure that everyone understands their role and the importance of their contributions to the overall compliance effort.
Invest in Training and Awareness: Ensure that your team understands the importance of CUI and export controls. Tools like a Compliance Copilot can be invaluable in providing guidance and answering questions in real-time.