CMMC Level 1 is designed to be the foundational level of the Cybersecurity Maturity Model Certification (CMMC), verifying that small defense contractors and manufacturers have basic safeguarding requirements in place to protect contract information. The problem is that these requirements don't seem so basic, so they have to hire a consultant or C3PAO for advisory services to translate instead.

Since many don't have the budget to do so, we created this guide as a translation. It covers the four key steps in order: define your scope, decide where Federal Contract Information (FCI) will live, implement all 15 requirements and 59 assessment objectives, then score and submit the result. For each Level 1 requirement, we break down what it's asking in plain language, what specifically you need to do to implement it, what evidence to prove it, and the pitfall that most often causes a small contractor to fail to fully implement or maintain it.

Let's get started.

What are the CMMC Level 1 requirements at a glance?

CMMC Level 1 is designed to verify that you have implemented the 15 basic safeguarding requirements from FAR clause 52.204-21 (now renumbered to FAR 52.240-93), which are organized into six domains. These domains map to 6 of 14 total NIST SP 800-171 Rev 2 families. Beneath those 15 requirements sit 59 assessment objectives, the determination statements you actually assess and score yourself against.

Before we dive into technical implementation of these cybersecurity requirements, here's what you need to know about the assessment requirements at this level:

• You assess yourself. Level 1 has never required a third-party assessor. No C3PAO is involved at this level.
• It is pass or fail. Each requirement is scored MET or NOT MET. There is no numeric score at Level 1.
• Assess against the objectives. A requirement is MET only when every one of its assessment objectives is satisfied.
• There is no partial credit. You cannot defer an unmet requirement to a Plan of Action and Milestones (POA&M). POA&Ms are not available at Level 1 in any form.
• NOT APPLICABLE is only allowed with contractually documented approval. NOT APPLICABLE (N/A) is only used if you have contractually documented approvals to not have to meet that requirement. If you don't have that approval but a requirement genuinely does not apply to your environment, then you mark it MET and explain what isn't in scope for that requirement.
• A named executive signs for it. Your Affirming Official attests that you have implemented and will maintain the requirements, which carries liability under the False Claims Act.
• It must be completed annually. A Final Level 1 Self-Assessment converts to No CMMC Status one year from your assessment date, automatically and without warning. You must submit a self-assessment and affirmation every year to keep a current status.

Step 1: Define your scope

Every asset, person, facility, and external service provider that processes, stores, or transmits FCI is in-scope for CMMC Level 1. Everything else is out of scope and never gets assessed. Getting this right is the single most important lever in how much work Level 1 is or isn't for a small defense contractor.

FCI is information provided by or generated for the government under a contract that is not intended for public release, such as technical specifications, proposals and bids, project schedules, supplier information, and non-sensitive internal communications.

When scoping, ask yourself four questions:

1. Which contracts bring FCI in? Read the clauses. If FAR 52.204-21 (or FAR 52.240-93 in newer contracts) appears, you are in scope.
2. How does FCI arrive and where does it land? For most small contractors it arrives by email or a file-sharing link and lands in a shared folder or a local drive.
3. Who touches it? Name the roles, not the headcount. Estimators, project managers, and design staff usually touch FCI. Payroll and accounts receivable usually do not.
4. Which outside parties reach it? Your IT provider, your file-sharing service, and any subcontractor you share contract or project management documents with.

For a typical small subcontractor this list is shorter than expected. As an example, take a 15-person mechanical contractor pursuing Level 1 for military housing work. They scope in the office staff who handle project files, their laptops and phones, the email and file-sharing tools those files pass through, and the on-premise drive where they land. Accounts payable, payroll, and field subcontractors who never see FCI stay out.

Takeaway: Every asset you can honestly leave out of scope is one less thing you need to apply 15 requirements and 59 objectives to.

Step 2: Decide where FCI will live

At Level 1, an on-premise server, government cloud, or commercial cloud may be used to process and store FCI. What matters is that the environment satisfies the 15 requirements and 59 objectives. While an enclave approach can concentrate FCI into a smaller boundary and shrink scope, most organizations at this level opt for an enterprise or "all in" approach for operational simplicity.

For most contractors looking to store and process FCI in the cloud, Microsoft 365 Commercial or another commercial productivity suite like Google Workspace that they're familiar with and often already paying for is acceptable. That single fact removes the largest cost item most Level 1 contractors assume they are facing.

Do you need GCC High for CMMC Level 1?

No. Level 1 protects FCI, not CUI. That means the DFARS 252.204-7012 clause that mandates cybersecurity and data residency and sovereignty requirements and drives GCC High adoption applies at Level 2 and above.

Microsoft's own guidance confirms that you can demonstrate compliance with CMMC Level 1 for the protection of FCI in Microsoft 365 Commercial as well as the government clouds. However, it notes that Microsoft 365 Commercial was not purpose-built for US government requirements, and the safer long-term risk posture is adopting one of the government cloud offerings.

The deciding question is whether it's plausible your next two years of contracts will include CUI. If you expect to bid on work that flows down DFARS 252.204-7012 or CMMC Level 2 requirements, moving to GCC High now avoids a migration later. If you handle FCI only, commercial is a defensible choice and the one most Level 1 contractors make.

Is Microsoft 365 Business Premium a good option?

Yes, Microsoft 365 Business Premium offers an affordable licensing tier, especially for small contractors with CMMC Level 1 requirements.

Business Premium bundles:

• Entra ID for identity
• Intune for device management
• Defender for Business for malicious code protection
• and Purview for data security and compliance.

Configured correctly, these primary and secondary services provide coverage across 14 of 15 requirements (93%) and all six domains, according to the June 2025 Microsoft Product Placemat (obtained directly from Microsoft's Richard Wakeman).

Note that this product placemat only maps service coverage to the high-level cybersecurity requirements, not the underlying assessment objectives.

Note that Google Workspace offers comparable control coverage through its Admin console directory, endpoint management, and sharing controls.

No license or cloud offering provides out-of-the-box compliance. You must still document, configure, and implement certain controls and practices within your environment. For example, if you have a facility, printer, or other equipment that handles FCI, then you’ll need locks, visitor logs, and key management to meet requirements PE.L1-B.1.VIII and PE.L1-B.1.IX.

Bottom line: At CMMC Level 1 especially, you can evaluate and buy licenses based on capability, not the highest compliance watermark. For FCI-only work, Microsoft 365 Commercial and Google Workspace are sufficient and can significantly reduce the burden of implementation and maintenance of the underlying cybersecurity requirements.

As a Microsoft reseller, Secureframe offers competitive pricing on Microsoft 365 licenses, including Business Premium for Microsoft 365 Commercial, GCC, and GCC High. Browse licenses on our Marketplace.

Step 3: Implement all 15 requirements

Each domain opens with a reference table you can scan, followed by implementation detail for each requirement. For the full objective-level breakdown or to track your control implementation, download our CMMC Level 1 compliance checklist.

Access control (AC): 4 requirements, 19 objectives

AC.L1-B.1.I: Limit system access to authorized users, processes, and devices

Objectives: [a] through [f]

What satisfies it

• Documentation of the users, processes initiated on their behalf (such as automatic updates or vulnerability scans), system accounts, and devices that can access the company network and information systems containing FCI
• Proof that these lists have been reviewed and reflect current employees, accounts, and devices
• Policies, procedures, and/or configuration settings in place that define and enforce how access is limited
• A record showing that account requests are authorized before system access is granted

Evidence to prove it may include

• Current user and asset inventory
• A record of your most recent user access review
• An access control policy
• Configuration settings or logs showing how your login systems work
• A log of additions, deletions, and modifications of user accounts based on access requests or changes in JIRA or a similar ticketing system

Common gap

• Shared accounts: A single "office" login used by four people fails [a] and [d] at once, because you cannot identify authorized users individually.

AC.L1-B.1.II: Limit access to permitted transactions and functions

Objectives: [a] and [b]

What satisfies it

• Role-based permissions that are clearly defined and enforced
• Implementation of the principle of least privilege (ie. denying access by default and allowing it by exception)
• A record showing how functional access or permissions is formally requested, approved, and removed when roles change or employees onboard or leave

Evidence to prove it may include

• An access control policy that defines which roles are permitted access to systems and apps containing FCI and to which functions (create/ read/ delete / update)
• A stand-alone role-based access control matrix (RBAC) or an export/screenshot of RBAC settings from Microsoft Entra ID or a similar tool
• A log of additions, deletions, and modifications to user roles, functional access, or permissions in JIRA or a similar ticketing system

Common gap

• Overly permissive defaults: An access control policy that doesn't clearly define permitted functions by role or mandate regular reviews of roles and permissions may assign overly permissive defaults or drift toward those over time, failing both objectives.

AC.L1-B.1.III: Verify and control connections to external systems

Objectives: [a] through [f]

What satisfies it

• Documentation of in-scope external systems and whether each is permitted to access corporate networks and how (ie. only certain employees may be allowed to connect to outside systems using a VPN, or only for certain windows of time)
• Policies, procedures, and/or configuration settings in place that define and enforce how external connections are limited
• Tools like firewalls, connection allow/deny lists, and VPNs

Evidence to prove it may include

• An access control policy that defines which external systems can connect and which can't (for example, it may require employees to use company laptops, not personal laptops, when working remotely on contract work involving FCI)
• List of external system connections with date of last review and approval
• Terms and conditions that address the types of applications that can be accessed from external systems at a minimum (also known as "Terms of Service")
• A record of your most recent network configuration review, including firewall rules, VPN configurations, and network architecture
• Log of any changes completed as identified during review (such as a screenshot of updated configurations or an incident ticket)

Common gap

• Personal cloud storage: Someone syncing project files containing FCI to a personal cloud or email account breaks [e] and [f], although it may be an unintentional violation. Ideally, that's why the use of external connections should be limited by a policy and a physical control.

AC.L1-B.1.IV: Control information posted on publicly accessible systems

Objectives: [a] through [e]

What satisfies it

• Documentation of who is allowed to post to your website or social accounts
• An established review process before anything goes up
• Procedures to remove FCI if it is accidentally published to the public

Evidence to prove it may include

• An access control policy that clearly defines roles and responsibilities for publishing, reviewing, and when necessary deleting publicly accessible content
• Security awareness training materials or records for authorized posters
• Export of permissions in your content management system (CMS)
• Logs of access attempts or changes in CMS or reviews and approvals for published content

Common gap

• Social media accounts: If you have no website, this requirement can be assessed as NOT APPLICABLE if you have contractually documented approval or IMPLEMENTED with an explanation for what’s not in scope. But any public presence at all, including a company page on a social platform or press releases, makes it applicable.

Identification and authentication (IA): 2 requirements, 6 objectives

IA.L1-B.1.V: Identify users, processes, and devices

Objectives: [a] through [c]

What satisfies it

• Documentation of the unique identifiers of every user that accesses company systems (i.e., usernames) and every device (i.e., IP address)
• Policies, procedures, and/or configuration settings in place that define and enforce how users, devices, and service accounts are identified and differentiated during registration or login

Ensuring that every user, process, and device has a vetted and trusted identity makes the access control requirement AC.L1-B.1.I possible.

Evidence to prove it may include

• A password policy defining procedures for assigning and tracking user, device, or service account identities
• List of personnel, service, and root accounts including their access keys, key count, and when the keys were last used

Common gap

• Generic logins: This is among the easiest requirements to satisfy and can be done with a password policy that mandates default usernames be changed (among other requirements). The entire Identification and Authentication domain is basic account hygiene. If every person has their own login and has to enter a password, you are close to done.

IA.L1-B.1.VI: Authenticate identities before granting access

Objectives: [a] through [c]

What satisfies it

• Defined password requirements, including minimum length
• Defined requirements if using other authenticator type, like requiring a one-time password be used within a certain time window
• Proof of how authentication is enforced for users, service accounts, and devices

Evidence to prove it may include

• Password policy defining requirements for length, complexity, and changing factory/default passwords
• Export or screenshot of authentication settings, including passwords and trusted devices
• Records of devices enrolled in Intune or similar MDM solution
• Records of MFA enrollment for users can be provided (although not required)

Common gap

• Overengineering: The most common way to verify identity at this level is using a username and a hard-to-guess password. Level 1 does not require multi-factor authentication. That is NIST SP 800-171 requirement 3.5.3 and applies at CMMC Level 2 or higher. You may choose to enable it anyway because credential compromise is one of the most common ways small contractors get breached and you will need it if you move up, but it is not required to reach a MET result at Level 1.

Media protection (MP): 1 requirement, 2 objectives

MP.L1-B.1.VII: Sanitize or destroy media containing FCI before disposal or reuse

Objectives: [a] and [b]

What satisfies it

• Documentation of the types of media that carry FCI in your environment (laptops, external drives, USB sticks, CDs, mobile devices, paper, etc.)
• Established procedures for disposing of each type, such as remote wipe for laptops, physical destruction for removable drives, and crosscut shredding for paper
• A record of every time media is disposed of or reassigned

Evidence to prove it may include

• Media protection policy or procedure defining approved sanitization methods by media type
• A log of every disposal with the date, asset identifier, method, and who performed the action (i.e., a remote wipe record in Intune)
• Vendor agreements if third-party destruction services are used

Common gap

• Unsanitized reuse: Most contractors handle disposal and forget reassignment, which fails objective [b] on its own. Handing a laptop from a departing employee to a new hire counts even though the device never leaves the building. Paper is a close second, since printed drawings and submittals routinely end up in a recycling bin instead of a shredder.

Physical protection (PE): 2 requirements, 10 objectives

No software satisfies this domain. It is where a fully cloud-based contractor still has work to do, and the domain small contractors most often skip.

PE.L1-B.1.VIII: Limit physical access to systems, equipment, and operating environments

Objectives: [a] through [d]

What satisfies it

• Documentation of individuals authorized for physical access to information systems, equipment, and operating environments
• Mechanisms like locks or badge readers to limit physical access to the office, network or server closet, cabinets, safes, or any sensitive areas

Evidence to prove it may include

• Physical security policy defining who is authorized and what is secured
• Photos or a floor plan marking secured areas and access points
• Record of badge assignments, key issuances, or revocation in the event of a termination or role change

Common gap

• Unsecured network equipment: A locked front door may satisfy the requirement for the environment [d] but not the rest if the switch, router, and backup drive sit in an open hallway or an unlocked utility closet.

PE.L1-B.1.IX: Escort visitors, maintain physical access logs, and manage physical access devices

Objectives: [a] through [f]

What satisfies it

• Established procedures for escorting and monitoring visitors, including general contractors, vendors, and delivery drivers, while in areas where FCI is processed or stored
• A visitor log or sign-in sheet at the front desk capturing name, company, date, time in and out, and who escorted them
• An inventory of physical access devices that's updated and maintained when an employee leaves or changes roles

Evidence to prove it may include

• Physical security policy and/or training materials that include visitor management procedures
• Completed visitor log from the front desk capturing name, company, date, time in and out, and who escorted them
• An up-to-date list of key, badge, and fob holders with date of last review
• An offboarding checklist including collection of physical access devices

Common gap

• Key inventory: Objectives [d], [e], and [f] cover identifying, controlling, and managing physical access devices, and small contractors may not maintain who holds which key, badge, or key card or even have written it down in the first place.

System and communications protection (SC): 2 requirements, 10 objectives

SC.L1-B.1.X: Monitor, control, and protect communications at system boundaries

Objectives: [a] through [h]

What satisfies it

• Defined external system boundary and key internal boundaries
• Firewalls, web proxies, gateways, and other protections in place to monitor, control, and protect the flow of data passing between boundaries
• A default-deny inbound rule with defined exceptions for all network boundaries

Evidence to prove it may include

• Network security policy
• An architecture and network diagram and/or data flow diagram including the system components and tools supporting the flow of data
• Export or screenshots of firewall configuration settings, record of last review, and any changes
• Firewall, network, or IPS logs and alerts configured to monitor traffic and detect anomalies

Common gap

• Architectural controls: A common mistake is to think encryption protects boundaries. It doesn't. It protects data. Logical separation requires architectural controls such as firewalls, VLANs, routing rules, and network enforcement mechanisms.

SC.L1-B.1.XI: Separate publicly accessible components from internal networks

Objectives: [a] and [b]

What satisfies it

• Documentation of any publicly accessible system components
• A dedicated VLAN, isolated cloud environment, security groups, or subnetworking that physically or logically separates any systems that you do host publicly
• A default-deny inbound rule from those subnetworks to your internal network containing FCI

Evidence to prove it may include

• The list of publicly accessible components, or a documented statement that you have none
• A network diagram showing physical or logical separation of public-facing systems
• Switch or firewall configuration settings showing access is restricted between public and internal systems

Common gap

• Undocumented inventory: Objective [a] is inventory, not configuration. Mapping firewall evidence here without ever identifying your publicly accessible components leaves [a] unsatisfied, and it is a common mapping error in compliance tooling as well as in self-assessments.

System and information integrity (SI): 4 requirements, 12 objectives

SI.L1-B.1.XII: Identify, report, and correct system flaws in a timely manner

Objectives: [a] through [f]

What satisfies it

• Documented timeframes for identifying, reporting, and correcting flaws (can be as simple as "critical patches within 14 days, all others within 30 days")
• A mechanism that performs the patching, such as Windows Update for Business, Intune update rings, or a managed service provider's patching service
• Proof that servers and user devices actually meet the timeframe

Evidence to prove it may include

• Vulnerability and patch management policy containing timeframes and defined process for reviewing vendor notifications and updates
• Patch compliance reports showing current status of servers and devices
• Ticketing or tracking records showing when flaws were reported and corrected

Common gap

• Overreliance on automatic updates: Contractors may patch diligently and never write the timeframe down, which fails half the requirement. Automatic updates alone cannot satisfy [a], [c], or [e], because those objectives ask whether the timeframe is specified, not whether patching happens.

SI.L1-B.1.XIII: Provide protection from malicious code at appropriate locations

Objectives: [a] and [b]

What satisfies it

• Documentation of the designated locations where malicious code protection is needed
• Endpoint protection deployed at all of them, such as an EDR tool like Microsoft Defender for Business or an anti-virus software
• Coverage that matches your scope, including mobile devices, email gateways, shop-floor machines, and any shared workstation that touches FCI
• Non-traditional mechanisms (i.e., secure coding and configuration management controls) if you have custom-built software

Evidence to prove it may include

• Malware protection policy identifying designated locations, including both system entry and exit points
• An endpoint deployment, coverage, and/or monitoring report or dashboard
• Export or screenshot of endpoint protection configuration settings
• Logs of actions initiated by the protection mechanisms (such as email filtering logs) and by personnel to address false positives (such as incident reports)

Common gap

• Endpoints missing from deployment: Usually it's a shop-floor machine, a shared workstation, or a tablet nobody counted as in scope. The gap is a scoping failure more often than a tooling failure.

SI.L1-B.1.XIV: Update malicious code protection mechanisms when new releases are available

Objectives: [a]

What satisfies it

• Defined frequency for malicious code protection mechanisms to be updated
• Logs or records of those updates

Evidence to prove it may include

• A configuration screenshot showing automatic updates are enabled
• Update logs from your EDR platform console
• Alerting records of any update failures and tickets tracking remediation

Common gap

• Manual process: This requirement is one of the easiest to meet thanks to automatic updates. Relying on a manual process increases the risk of failed or untimely updates.

SI.L1-B.1.XV: Perform periodic and real-time scans

Objectives: [a] through [c]

What satisfies it

• A defined scan frequency in writing, which is objective [a]
• Scheduled scans configured to match that frequency
• Real-time protection enabled so files from external sources are scanned as they are downloaded, opened, or executed

Evidence to prove it may include

• Malware protection policy stating the scan frequency
• Scan history or logs showing scans ran at that frequency
• Real-time protection configuration settings

Common gap

• Default schedule: The same pattern as flaw remediation. Your endpoint protection ships with a default schedule that may suit your needs, but it must be evaluated first and then documented to satisfy objective [a].

What CMMC Level 1 does not require

Most of the cost and anxiety at Level 1 comes from assuming Level 2 work is required. But Level 1 is a foundational level that rolls up to CMMC Level 2.

Implementing the underlying cybersecurity requirements at this level provides a headstart for Level 2 and other more advanced frameworks. None of the following is required to reach a MET result at Level 1:

Step 4: Score, submit, and affirm

Once every requirement is implemented, you run a readiness check, score the assessment, and record it in the Supplier Performance Risk System (SPRS) through the Procurement Integrated Enterprise Environment (PIEE) portal, and your Affirming Official signs the affirmation.

The overall result is MET only if all 15 requirements and 59 objectives are satisfied (or marked as NOT APPLICABLE with contractually documented approval). Only a status of Final Level 1 Self-Assessment makes you eligible for awards carrying the Level 1 requirement, and it expires one year from your assessment date. Primes cannot see your SPRS record directly, so expect to be asked for a screenshot.

Step 5: Keep your Level 1 status current

The affirmation is what turns Level 1 from an annual project into an ongoing obligation. You are attesting not just that you met the requirements on assessment day, but that you are maintaining them.

That distinction is where most contractors get into trouble. Access reviews stop happening, a laptop leaves without being wiped, a former employee keeps a key, antivirus falls off a machine. None of it is dramatic, and all of it makes a signed affirmation inaccurate. Build the recurring habits now: a quarterly access and key review, a disposal log you actually fill in, and a check that endpoint protection still covers every in-scope device.

Get secure and stay CMMC compliant with Secureframe

CMMC Level 1 requires you to assess your implementation of 15 requirements and 59 objectives, and for a small contractor with a tight scope, most of them are satisfied by the right configurations of tools you already own plus decisions you just need written down.

The three things that will save you the most time are scoping honestly so you assess only what's necessary, choosing a cloud solution and license for what it does rather than for its compliance label, and finding an affordable and scalable way to implement and maintain the underlying Level 1 requirements that are foundational to compliance with NIST 800-171, DFARS 7012, CMMC Level 2, and other cybersecurity frameworks.

You do not need a consultant, an RPO, or an advisory C3PAO to do this necessarily. You need an accurate mapping of the 15 requirements and 59 objectives to the controls you need in place and the tests to ensure they're operating effectively, an honest look at your environment and what touches FCI (and whether it touches any CUI), and the operational discipline to keep it current between assessments.

Secureframe Defense automatically maps controls and collects evidence for all Level 1 requirements and objectives that apply to your environment, and monitors them between assessments so the affirmation you sign every year reflects your actual environment.

Request a demo to see how we help contractors of all sizes stand up and manage a NIST 800-171 and CMMC cybersecurity program to keep their contracts and operations running.