This is the first blog in a three-part series on the role of identity in CMMC 2.0.
BLUF: A critical question that underpins every access policy: Are you really who you say you are?
This post dives deep into the Identification and Authentication (IA) control family. We’ll demonstrate why strong identity verification is the mandatory prerequisite for a more secure access control and show how Okta helps you meet these requirements at every level of CMMC 2.0 maturity.
An Overview: Authentication is the Bedrock of Access Control
The Identification and Authentication (IA) control family is the digital gatekeeper for your organization. Its purpose is to ensure every user, device, or process is legitimate and verified before it can even attempt to access a resource. Your carefully crafted Access Control (AC) policies are meaningless if you question the certainty of the identity making the request.
This is why the CMMC 2.0 scoring methodology places such a heavy emphasis on the IA controls. An auditor must have certainty in and proof of the identity before they can trust the security measures you have in place.
With Okta, organizations can immediately address a significant portion of these high-value requirements. Within the IA family alone, Okta helps you meet three controls worth 5 points—the "big rocks" that are essential for passing your audit.
Let's explore a key IA control at each CMMC level.
CMMC Level 1: The Foundational Layer
Level 1 focuses on "basic cyber hygiene" and is required for contractors handling Federal Contract Information (FCI). It ensures you have the essentials in place.
Key Level 1 Control: IA.L1-3.5.1
CMMC Requirement | NIST SP 800-53 Correlated Control |
|---|---|
IA.L1-3.5.1: Identify and authenticate information system users, processes, or devices. | IA-2: Identification and Authentication (Organizational Users): The information system uniquely identifies and authenticates organizational users (or processes acting on behalf of organizational users). |
This control requires you to issue a unique identity to every user and eliminate shared accounts.
How Okta Meets the Control:
The Okta Universal Directory and Single Sign-On (SSO) are the perfect tools for this CMMC requirement. Okta acts as the central source of truth for all user identities, ensuring every person has one, and only one, account. By federating your applications with Okta SSO, you help ensure this single, unique identity is used for every login, making shared accounts a thing of the past.
- Real-World Scenario: A small DIB supplier logs into a prime contractor's portal to access FCI, like delivery schedules. Instead of using a shared shipping@supplier.com account, the company uses Okta to give each employee a unique user account. When an employee accesses the portal, they authenticate with Okta using their personal credentials, ensuring every action is tied directly to them and meeting the basic traceability required for Level 1.
IA.L1-3.5.1 Design Recommendations:
To implement this control, configure Okta as your central identity provider by connecting it to a source of truth, such as your HR system, or by creating user profiles directly in the Okta Universal Directory. For each of your applications, configure a SSO integration using SAML or OIDC. Critically, ensure the application is set to allow logins only via Okta, disabling the ability for users to create separate local accounts with a username and password. This enforces the use of the single, managed identity for all access.
IA.L1-3.5.1 Compliance Evidence:
To demonstrate compliance to an assessor, you would show them your Okta Universal Directory to prove that each employee has a unique user profile. Then, you would navigate to the configuration page for a key application (e.g., Microsoft 365) and display the SSO settings, noting that it is federated with Okta. Finally, you would pull up the Okta System Log, filter for a specific user's recent login, and show the detailed event log, proving that every action is traceable to a unique actor.id.
CMMC Level 2: The CUI Gatekeeper
Level 2 is for contractors handling the more sensitive Controlled Unclassified Information (CUI). This level is aligned with NIST SP 800-171 and requires much more robust security.
Key Level 2 Control: IA.L2-3.5.3
CMMC Requirement | NIST SP 800-53 Correlated Control |
|---|---|
IA.L2-3.5.3: Use multifactor authentication for local and network access. | IA-2(1): Network Access to Privileged and Non-Privileged Accounts: The information system implements multifactor authentication for network access to privileged and non-privileged accounts. |
This 5-point "big rock" control mandates that a password alone is not enough. You must enforce a second verification factor (MFA) to protect against password theft.
How Okta Meets the Control:
Okta Adaptive MFA is the perfect tool for this CMMC requirement. As a centralized identity provider, Okta can enforce strong MFA for every access attempt to any application handling CUI. Policies can be set to require MFA for all users and can adapt based on risk, such as requiring a stronger factor when a user is connecting from an untrusted network.
- Real-World Scenario: An aerospace engineer working from home needs to access a cloud-based CAD application containing CUI. To log in, they first enter their password. Okta then prompts them to approve a push notification on their registered smartphone. Only after they approve this second factor are they granted access to the sensitive design files. An attacker who phished their password would be stopped cold at the MFA challenge.
IA.L2-3.5.3 Design Recommendations:
In your Okta admin console, create an "Authenticator Enrollment" policy that requires all users to enroll in at least one MFA factor. Then, create a "Sign-On Policy" and apply it to all applications that handle CUI. Configure the rules within this policy to "require multifactor authentication" for every login. A best practice is to set the rule that if a user is on an untrusted network, they are always challenged for MFA. For an even stronger posture, require a phishing-resistant factor for all access to these critical apps.
IA.L2-3.5.3 Compliance Evidence:
For an assessor, you would first display the sign-on policy you created, showing the rule that explicitly enforces MFA on every login to a CUI-bearing application. You would then perform a live demonstration: attempt to log in to that application as a test user and show the assessor the live MFA prompt appearing on a registered device. Finally, show them the corresponding "Multifactor authentication" success event for that user in the Okta System Log.
CMMC Level 3: The Expert Defense
Level 3 is for organizations in the DoW's highest-priority programs. It requires all L2 controls plus enhanced controls from NIST SP 800-172 to protect against Advanced Persistent Threats (APTs).
Key Level 3 Control: IA.L3-3.5.4e
CMMC Requirement | NIST SP 800-53 Correlated Control |
|---|---|
IA.L3-3.5.4e: Employ phishing-resistant multifactor authentication for all privileged and non-privileged access. | IA-2(8): Phishing-Resistant / Replay-Resistant: The information system uses authentication mechanisms that are phishing resistant and replay resistant. |
This advanced control mandates the use of phishing-resistant MFA to defeat sophisticated attacks that can bypass weaker MFA types.
How Okta Meets the Control:
Okta has some of the industry’s strongest phishing-resistant authenticators, which are the tools that meet this CMMC expert-level requirement. These include FIDO2/WebAuthn-compliant hardware security keys like YubiKeys, and passwordless solutions like Okta FastPass, which leverages platform biometrics such as Windows Hello or Apple's Face ID/Touch ID. Okta's policies can be configured to exclusively require these unphishable factors for any user accessing the high-value CUI environment.
- Real-World Scenario: A cybersecurity analyst at a top-tier defense firm manages systems containing highly sensitive CUI. To access the administrative console, they must authenticate through Okta. After entering their password, they are prompted to touch the YubiKey inserted into their workstation. The key performs a cryptographic challenge-response that is unique to them and the Okta service, proving their identity with the highest level of assurance and making it impossible for a sophisticated adversary to intercept their credentials.
IA.L3-3.5.4e Design Recommendations:
In your Okta "Authenticator Enrollment" policy, ensure that FIDO2/WebAuthn authenticators are enabled. Then, create or edit your Sign-On Policy for CUI applications. Instead of a general MFA requirement, create a rule that explicitly requires an authenticator with "Phishing Resistance" as a required property. This rule will force the use of factors like a YubiKey, or Okta FastPass, leveraging a device's built-in biometrics, and will not permit weaker factors like SMS or security questions for accessing these high-sensitivity applications.
IA.L3-3.5.4e Compliance Evidence:
To demonstrate this to an assessor, you will show them the Sign-On Policy rule you configured that specifically requires phishing-resistant authenticators. Then, perform a live login demonstration. First, attempt to log in using a non-phishing-resistant factor (like a push notification) and show that access is denied. Then repeat the login using a YubiKey or Okta FastPass with Windows Hello, and verify that access is successfully granted. This provides undeniable proof of enforcement.
Continue Your CMMC Journey on a Solid Foundation
By pairing strong Access Control with resilient Identification and Authentication, you build a formidable defense for your CUI and a solid foundation for your CMMC audit. Centralizing your strategy on a modern identity platform ensures that the right people—and only the right people—get access to the right resources.
Stay tuned for our next post in the series, where we will explore the Audit and Accountability (AU) domain to show how you can prove your security controls are working as intended.
To learn more about how Okta can help your organization meet CMMC requirements, download our CMMC Discovery Guide at https://www.okta.com/resources/datasheet-okta-cmmc-discovery-guide/ or contact us at okta.com/contact-sales/.
While this article discusses certain legal concepts, it does not constitute legal advice and should not be construed as such. It is provided for informational purposes only. For legal advice regarding your organization's compliance needs, please consult your organization's legal department. Okta makes no representations, warranties, or other assurances regarding the content of this article. Information regarding Okta's contractual assurances to its customers can be found at okta.com/agreements.
