What is CMMC (Cybersecurity Maturity Model Certification)?

The CMMC program, Cybersecurity Maturity Model Certification, was pioneered by the U.S. Department of Defense to measure and verify the level of implementation of processes and practices in the area of cybersecurity at its suppliers.

The ultimate purpose of the CMMC, through its maturity levels (see below) is to serve as a verification mechanism for Defense Industrial Base (DIB) suppliers to implement cybersecurity processes and practices to protect two types of information:

  • Controlled Unclassified Information, as referred to in NIST 800-171, is information that requires protection or disclosure controls in accordance with government laws and policies, but is not In short, it is sensitive information, relevant to the interests of the United States, but not strictly regulated by the Federal Government.

The U.S. Government maintains a CUI Registry with categories and subcategories of this type of information:

  • Critical Infrastructure
  • Defense
  • Export Control
  • Financial
  • Immigration
  • Intelligence
  • International Agreements
  • Law Enforcement
  • Legal
  • Natural and Cultural Resources
  • NATO
  • Nuclear
  • Privacy
  • Procurement and Acquisition
  • Proprietary Business Information
  • Provisional
  • Statistical
  • Tax
  • Federal Contract Information (FCI) is non-public information that is provided or generated by the government in connection with a contract to develop or deliver a product or service to the

The following image shows the relationship between FCI, CUI and Public Information:

relationship FCI CUI Public Information


At a high level, this model is a collection of processes and practices from other standards and regulations such as NIST, FAR, and DFARS among others. The following chart shows a summary of CMM coverage with respect to other standards including NIST SP 800-171.


Who does it apply to and why is it important?

This certification applies to both Department of Defense prime contractors and their subcontractors. It became effective in November 2020 and some level of certification will be required for all contracts beginning in 2026.

The cost of cybercrime globally exceeds $1 trillion, and has grown by 50% since 2018, which is more than 1% of GDP generating global losses of $600 billion. 75% of those of the losses are related to intellectual property theft and financial crime.

The cost of cybercrime is estimated to continue to grow, and according to other analyses, will reach $10.5 trillion annually by 2025.

In May 2021, U.S. President Joe Biden signed an executive order to improve U.S. cybersecurity following the computer attack on the Colonial pipeline, the country’s most important oil pipeline, which was forced to shut down to protect operating systems. This executive order involves the establishment of baseline cybersecurity standards for all software purchased by the government to improve security throughout the supply chain. Among other issues, the order requires the deployment of the use of encryption by the Government within a very tight timeframe (6-9 months).

This is why CMMC and compliance with cybersecurity standards will become increasingly important in the coming years for all U.S. government suppliers.

The CMMC model and its 5 levels

CMMC and its relation to NIST 800-171

One of the standards on which CMMC is based is 800-171 created by NIST to help fundamentally protect Controlled Unclassified Information (CUI) in non-federal or government organizations. NIST 800-171 was developed after FISMA (Federal Information Security Management Act) which resulted in different security guidelines and standards.

Passing a CMMC audit does not imply that an organization meets or is “compliant” with NIST 800-171. CMMC only focuses on controls related to Controlled Unclassified Information (CUI), but NIST 800-171, in addition to the 110 CUI controls, includes 63 NFO (Non-Federal Organization) type controls.



Unlike NIST SP 800-171, the CMMC model consists of five levels. The model is cumulative so each level consists of practices and processes as well as those specified in the lower levels. The CMMC model includes additional cybersecurity practices on top of the security requirements specified in NIST SP 800-171.

In addition to assessing the implementation of a company’s cybersecurity practices, the CMMC also evaluates the company’s maturity processes.

CMMC Level 3 includes the 110 security requirements specified in NIST SP 800-171. The CMMC model also incorporates additional practices and processes from other standards, references and/or sources such as NIST SP 800-53, Aerospace Industries Association(AIA) National Aerospace Standard (NAS) 9933 “CriticalSecurity Controls for Effective Capability in Cyber Defense”, and the Computer Emergency Response Team (CERT) Resilience Management Model (RMM).

The following table includes standards or frameworks on which CMMC is based:

FAR Clause 52.204-21
NIST SP 800-171 Rev 1
Draft NIST SP 800-171B
CIS Controls v7.1
NIST Framework for Improving Critical Infrastructure Cybersecurity (CSF) v1.1
CERT Resilience Management Model (CERT RMM) v1.2
NIST SP 800-53 Rev 4
Others like “UK NCSC Cyber Essentials” o “AU ACC Essential Eight”


CMMC Components: Domains, Capabilities, Practices and Processes

The CMMC model is organized into processes and security best practices within a subset of domains. The elements of the model are:

  • 17 Domains composed of Practices, organized in turn into
  • 43 Capabilities or collections of Cybersecurity
  • 171 Cybersecurity Practices
  • 5 Processes that are evaluated for Maturity Levels 1 to 5
  • 5 Certification Levels corresponding to the 5 Maturity

Domains, Capabilities, Practices and Processes

Each level has a set of Processes and Practices and a target for each in relation to the applicable Domains at that level. For example, achieving level 3 means that an organization has achieved the objective of having Processes that are Managed and Practices of a Good Cybersecurity Level.

The following table shows a summary of the Levels in relation to Process Maturity and Practices:

Levels in relation to Process Maturity


The following figure shows for each level the required practices of NIST 800-171 and other standards and regulations:

In summary, the list of practices by Level is as follows:


The following chart shows the relationship between the domains, and practices of each domain that refer to each level.


Focus or Objective of the Maturity Processes based on Type of Information

The CMMC model provides the means to improve the alignment of cybersecurity practices and maturity processes with the type and sensitivity of information to be protected and the types of threats. The levels can also be characterized in this regard by their focus:

  • Level 1: Safeguarding Federal Contract Information (FCI).
  • Level 2: Serve as a transitional step to protect
  • Level 3: Protect Controlled Unclassified Information (CUI).
  • Level 4-5: Protect CUI and reduce risks from Advanced Persistent Threats (APTs).


Zero-Trust model and CMMC

The Zero-Trust security model assumes that an attacker is present in the organization’s network and that an environment or network owned by the organization is no different, or no more trusted, than one not owned by the organization.

The objective of the model is to prevent unauthorized access to data by making access control as granular as possible. That is, authorized and approved subjects (combination of user, application, service and device) can access the data to the exclusion of all other subjects (i.e. attackers).

Federal agencies of the U.S. government have been encouraging organizations to adopt a security model based on Zero-Trust principles for more than a decade,

The US Government has been urging federal agencies to move to a security model based on Zero-Trust principles for more than a decade, developing capabilities and policies such as the Federal Information Security Modernization Act (FISMA).

The principles of the Zero Trust model are:

  • Ensure that data is accessed securely regardless of its location: Any connection to data is untrusted until proven otherwise, regardless of where it is made from.
  • Adopt the “least privilege access model” strategy and enforce strict access controls: An individual should be given access only to the resources he or she needs to perform his or her job and prevent access to the rest.
  • Inspect and monitor everything: Activity should be inspected not only at the network access point but also inside the network, trying to identify anomalous behavior.

This is a data-centric security model, where data security is at the heart of it. Keep in mind that the ultimate goal of security is not to protect the network, not the systems, not the devices, but to protect the most valuable thing, which is sensitive data.

zero trust data-centric security sealpath

CMMC places particular emphasis on organizations implementing cybersecurity processes and practices to protect two types of information as stated above: Controlled Unclassified Information (CUI) data and Federal Contract Information (FCI) data.

In the CMMC or NIST 800-171 Zero Trust is not explicitly mentioned, but for example in the Configuration Management (CM) part, organizations are asked to use the principle of best privilege access.

In July 2021, the US Administration issued a memo aimed at creating new cybersecurity practices for critical infrastructure, such as the electricity, natural gas and water sectors. These new practices will be based on NIST standards, including Publication 800-207, “Zero Trust Architecture (ZTA)” and according to some sources, a memo on CMMC and Zero Trust Architecture for the DIB (Defense Indutrial Base) is in the works.


SealPath’s Data-Centric Security approach in the context of the CMMC

A data-centric security approach is based on securing the organization’s most valuable content so that it can be protected against unauthorized departure from the network, cloud or data leakage.

We can know where the organization’s sensitive information is, and the level of classification, but it will be of little use if we do not put measures in place to protect this information wherever it travels.

SealPath, with a data-centric security approach, allows the organization’s documentation and files to travel persistently protected. The protection accompanies the document anywhere and can be controlled:

  • Who accesses the document (identity).
  • With which permissions such as view, edit, print, etc. (access level).
  • Until when (temporality of access).
  • From which subnets and IPs (place of access).

SealPath is aligned with a security strategy based on the Zero Trust model, so that users are given access only to the information they need, when they need it and with the minimum access permissions they require.

SealPath facilitates the implementation of different CMMC security practices. Below, we present a table organized by domains, and capabilities in which SealPath, with its data-centric security approach, can help. The CMMC Level to which the practice in question refers is also indicated.

It is important to note that a software solution alone does not enable compliance with a standard such as NIST 800-171 or to achieve certification of a CMMC audit, but rather this is achieved based on the implementation of different processes, practices and tools.

CMMC sealpath practices compliance


The following sections, organized by domain, detail in what capabilities and practices SealPath’s data-centric security solution can help with compliance.

A reference to the NIST 800-171 requirement related to the practice is also included. Only those practices where SealPath can assist in compliance are shown (boxed in blue).

Although the detail is shown indicating how SealPath can help, the following table includes a summary of the practice mapping, with its reference to the NIST 800-171 requirement where SealPath can help.

summary of the CMMC and NIST 800-171 practice mapping SealPath

Access Control (AC)

How does SealPath help to comply with these practices?

  • AC.1.001 / AC.2.002 – SealPath can limit and control who accesses sensitive files. Only authorized users can access and with the permissions assigned by the file owner (only view, edit, print, etc.).
  • AC.2.005 – SealPath provides security warnings on protected files indicating the protection policy, description, dynamic watermarks, etc.
  • AC.2.006 – Information travels protected, regardless of whether it is on a portable device or external storage system. Access will be controlled and limited equally depending on the permissions assigned to the user.
  • AC.2.007 – Only users are allowed access to what they should have access to and no more. The principle of least privilege applies, which is limited by the file protection policy.
  • AC.2.008 – Privileged accounts are not required to access protected sensitive information. In addition, certain users can access the data without the administrator users themselves having access to the data.
  • AC.2.009- SealPath has a policy of maximum number of attempts with the possibility of blocking the information if a certain number is exceeded.
  • AC.2.016 – The entire life cycle of the CUI is controlled based on the permissions delimited in the policy, and access to the information is only possible if the corresponding authorization is available.
  • AC.3.017 – SealPath allows a separation of duties so that a distinction is made between administrators who can access infrastructure management, and data managers who control policies or users who can access sensitive information.
  • AC.3.019 – It is possible to block access sessions to sensitive documentation by forcing a reset of credentials or simply removing users from documentation access policies or from the documentation itself.
  • AC.3.022 – Information remains encrypted on PCs, mobile devices, cloud platforms. Information access control and file protection travels with the documents.



How does SealPath help to comply with these practices?

  • AU.2.041 SealPath monitors access to protected sensitive documents so that you can audit who accesses them, when, from which IPs, and the permissions with which they access them.
  • AU.2.042 – SealPath keeps the monitoring logs in a database, which can be retained over time by simply expanding the space. On the other hand, the logs can be sent to a SIEM so that they can also be kept in this system.
  • AU.2.043 – Logs are synchronized with the system clock time. All log entries include the date and time.
  • AU.2.044 – The administrator has access to protected document access monitoring logs that can be reviewed and correlated with logs from other systems.
  • AU.3.045 / AU.3.046 – Both the data protector and the administrator can have access to who has opened a document, date and time, etc. Also alerts of blocked access attempts, failed login attempts, unprotected documents, etc.
  • AU.3.049 / AU.3.50 – Only a user who has protected a document has access to the monitoring information of that document. The administrator is the only person who can additionally access these logs. These logs are not modifiable and are stored in a database to which, in an on-premise deployment, only the database administrator has access.
  • AU.3.051 – Logs are timestamped and can be correlated with events occurring in other systems. It is possible to differentiate between the type of alert: Attempted access to a document without permissions, document unprotections, user invitations, etc.
  • AU.3.052 – Events or logs are post-processed and displayed to the administrator in the form of activity summary graphs. On the other hand, the information can be sent to a SIEM to be analyzed together with other events. From the SIEM it is possible to generate specific reports and send them to one or more persons.



How does SealPath help to comply with these practices?

  • AT. 3.058One of the fundamental parts of the SealPath implementation process is to make users aware of the need to adequately protect and manage the organization’s sensitive information. This article explains the deployment steps, one of the fundamental ones being “educate and communicate”.



How does SealPath help to comply with these practices?

  • CM.2.062Following the Zero Trust model, SealPath is based on the premise of giving users access only to what they need and only to what they need.
  • CM. 3.068It is possible to restrict or revoke the use of protected documents even if they have already been shared and are outside the organization’s network.



How does SealPath help to comply with these practices?

  • IA.1.076 / IA.1.077SealPath consists of a combination of identity management (checking who is accessing the information), permissions management (leaving only the necessary permissions) and encryption (at rest, in transit and in use). The user accessing or attempting to access the CUI is identified at all times.
  • IA.2.078 / IA.2.079 / IA.2.080 / IA.2.081 / IA.2.082SealPath allows you to manage different levels of password strength, including captchas after a first wrong attempt, limiting the number of false accesses allowed or forcing the change of credentials. There is integration with AD to establish this type of policies and if stored in a database, they are stored encrypted.
  • IA.3.083 / IA.3.084 – SealPath allows the use of multi-factor authentication and advanced authentication mechanisms, integrated with AD Federation Services.
  • IA.3.085 / IA.3.086 – It is possible to temporarily or permanently block or disable user IDs so that they cannot access protected documentation. On the other hand, it is possible to block access to users after a period of inactivity in an integrated way with AD.



How does SealPath help to comply with these practices?

  • IR.2.093 / IR.3.098 – Events of blocked access attempts to files, massive unprotections of documentation, accesses to files with a log of IP dates, etc. are recorded. These events are available to the document protector and to the security team. Events can also be reported through a SIEM so that, depending on the level of alert, response actions can be prioritized.



How does SealPath help to comply with these practices?

  • MA.3.115 – SealPath does not destroy or eliminate the information of equipment or devices that are removed. However, the information remains encrypted, with access control, being able to revoke access to it to certain IPs, users, etc. This revocation implies a “virtual” destruction of the information, since it remains inaccessible wherever it may be.



How does SealPath help to comply with these practices?

  • MP.1.118 – As described in requirement MA.3.115, SealPath does not destroy or delete FCI or CUI type information from devices that are removed. However, the information remains encrypted, with access control being able to revoke access to it for certain IPs, users, etc. This revocation implies a “virtual” destruction of the information, since it remains inaccessible wherever it is.
  • MP.2.119 / MP.2.120 / MP.3.124 – CUI in digital  format remains protected and under control at rest, in transit and in use. It is possible to limit who can access it, with which permissions, until when it is possible to access it, etc. This is done regardless of whether it is stored on a removable device such as a hard disk. Also when these devices are outside physical areas controlled by the organization.



How does SealPath help to comply with these practices?

  • PS.2.128 – When a person leaves the organization or moves from one computer to another, it is possible to transfer the permissions they have on certain CUI information to other people or simply restrict their access. This control can also be done synchronized with AD so that when a user is disabled or removed from AD he/she loses access to the documentation.



How does SealPath help to comply with these practices?

  • RE.2.138 – Information remains protected not only on users’ computers or file servers but also in backups. The administrator can choose to unprotect backup documentation if necessary, but an audit trail is kept of the actions taken by the administrator.



How does SealPath help to comply with these practices?

  • RM.2.141 / RM.2.143 – Audit and action tracking information on documents, alerts, etc. allows periodic analysis of whether the security policies set by the organization are being followed or whether modifications to the policies are necessary. It is possible to remedy possible deficiencies found by modifying security policies, creating new ones, etc. Within the deployment steps of a data-centric solution such as SealPath, it is recommended to “refine and evolve” the security policies as discussed in this article.



How does SealPath help to comply with these practices?

  • CA.2.158 / CA.3.161 – The security controls established in SealPath can be reviewed periodically to determine whether they are being effective or need to be modified. On the other hand, alerts can be monitored on an ongoing basis to verify their effectiveness or to make modifications based on the deficiencies or alerts detected.



How does SealPath help to comply with these practices?

  • SC.1.175 – SealPath allows you to protect attachments or message bodies sent inside and outside the organization. Also documentation that is exchanged with internal or external users by any means (Cloud sharing systems, collaboration tools, etc.). This documentation, emails and attachments can be monitored, and access and revocation permissions can be controlled, in addition to traveling encrypted.
  • SC.3.177 / SC.3.185 / SC.3.187 – SealPath employs FIPS-validated cryptographic systems, including the possibility of managing keys using an HSM. Protection travels encrypted and protected at rest, in transit and in use to prevent unauthorized access.
  • SC.3.181 – Infrastructure management and policy management functionalities by the administrator are separated from user functionalities. The fact that a user has access to certain sensitive information does not imply that an administrator also has access to it.
  • SC.3.182 / SC.3.188 / SC.3.191 – Documentation travels protected and under control so only authorized users will be able to access and with assigned permissions regardless of where the documentation is transferred. This includes mobile devices to which sensitive documentation is sent or stored. It also protects the confidentiality of access to the CUI at rest, wherever the CUI is located.
  • SC.3.190 Communications for access permission control are performed over secure HTTPS protocols using a Security Token Service (STS). The protocol used to deliver security tokens is based on WS-Trust, a Web service specification built on top of WS- Security.



A data-centric protection solution such as SealPath helps to keep information protected and under control in any environment. Following Zero Trust principles, it allows granular access to Confidential Unclassified Documentation (CUI) as well as confidential classified information. Users are allowed access only to what they need and only to what they need, and it allows monitoring of suspicious access behavior to the organization’s critical information.

Would you like to learn more about how SealPath can help you in your CMMC, NIST 800-171 certification process or to implement a Zero-Trust security model? Contact us.