Part 1: Security foundations for CMMC-ready systems

Nikos Katsikanis - April 15, 2026

I start with the source material, not the badge

Before a platform is called compliant, I want to see the security controls underneath it, the references they map to, and the evidence that shows they work. For the current NIST baseline, I start with NIST SP 800-171 Rev. 3 and NIST SP 800-171A Rev. 3, then cross-check the CMMC program rule, the DFARS Acronym Defense Federal Acquisition Regulation Supplement. The Department of Defense supplement to the federal acquisition rules used in defense contracting. 252.204-7012 clause, and the 252.204-7020 clause.

NIST withdrew Rev. 2 and 171A in May 2024 and replaced them with Rev. 3 and 171A Rev. 3, but the current DoD Acronym Department of Defense. The U.S. federal department responsible for national defense and the owner of the CMMC program. CMMC resources and CMMC overview still frame Level 2 around the 110 NIST SP 800-171 Rev. 2 requirements. That is why I still use the familiar 3.x.x control identifiers in this article.

NIST describes protecting CUI Acronym Controlled Unclassified Information. Sensitive information that is not classified but still requires safeguarding under U.S. government rules. in nonfederal systems as “of paramount importance.” That is the right starting point. The controls have to be real before the label means anything.

If I had to summarise why CMMC was introduced in the US in about 140 words

The U.S. already had rules telling defense contractors to protect sensitive contract data, especially CUI and FCI Acronym Federal Contract Information. Information provided by or generated for the government under contract that is not intended for public release. , but too much still depended on self-attestation. At the same time, the Defense Industrial Base was taking more frequent and more capable cyber hits. On the DoD Acronym Department of Defense. The U.S. federal department responsible for national defense and the owner of the CMMC program. CIO CMMC overview, DoD states that risk directly, and in the 2024 final rule it says the program moves away from a “self-attestation” model. I do not see CMMC as a new security theory. I see it as the U.S. turning existing defense cybersecurity requirements into something that can be checked and enforced.

Strong authentication is the front door

Security starts with identity. If a system cannot establish who the user is, the rest of the control set gets shaky fast.

At a minimum, I want to see 3.5.1 NIST SP 800-171 Rev. 2 Identify system users, processes acting on behalf of users, and devices. , 3.5.2 NIST SP 800-171 Rev. 2 Authenticate (or verify) the identities of users, processes, or devices, as a prerequisite to allowing access to organizational systems. , and 3.5.3 NIST SP 800-171 Rev. 2 Use multifactor authentication for local and network access to privileged accounts and for network access to non-privileged accounts. reflected clearly in the platform. In privileged admin areas, MFA Acronym Multifactor authentication. Login protection that requires more than one factor, such as a password plus a code or security key. should be deliberate, documented, and testable, with an assessment path that lines up with the current NIST SP 800-171A Rev. 3 procedures.

This matters more when a platform mixes public features with admin workflows. Sessions should not be trusted equally, and users should not move through the system with the same level of access.

Authorization matters just as much as login

Authentication answers who someone is. Authorization answers what they can do. Those two questions get blurred too often.

A system can have a clean sign-in flow and still fail basic security expectations if every authenticated user can see the same records or trigger the same actions. The permission model has to reflect real responsibilities.

For least privilege, I want actual 800-171 numbers: 3.1.1 NIST SP 800-171 Rev. 2 Limit system access to authorized users, processes acting on behalf of authorized users, and devices (including other systems). , 3.1.2 NIST SP 800-171 Rev. 2 Limit system access to the types of transactions and functions that authorized users are permitted to execute. , 3.1.5 NIST SP 800-171 Rev. 2 Employ the principle of least privilege, including for specific security functions and privileged accounts. , 3.1.6 NIST SP 800-171 Rev. 2 Use non-privileged accounts or roles when accessing nonsecurity functions. , 3.1.7 NIST SP 800-171 Rev. 2 Prevent non-privileged users from executing privileged functions and capture the execution of such functions in audit logs. , and 3.1.8 NIST SP 800-171 Rev. 2 Limit unsuccessful logon attempts. . Someone who manages events should not automatically get financial powers. Someone who reviews member records should not automatically be able to change platform-wide settings.

NIST SP 800-171 3.1.5

“Employ the principle of least privilege, including for specific security functions and privileged accounts.”

• It limits the blast radius when mistakes happen.
• It makes abuse harder when accounts are compromised.
• It creates clearer operational accountability.
• It supports separation of duties instead of shared-admin habits.

Session security still matters after login

Secure login is not enough if the session itself is weak. After authentication, the platform still has to defend the session against theft, misuse, and browser-based attacks.

NIST SP 800-171 does not speak in browser-cookie language, so I map that work back to the control families. For session handling, that means 3.1.1 NIST SP 800-171 Rev. 2 Limit system access to authorized users, processes acting on behalf of authorized users, and devices (including other systems). , 3.1.2 NIST SP 800-171 Rev. 2 Limit system access to the types of transactions and functions that authorized users are permitted to execute. , 3.13.8 NIST SP 800-171 Rev. 2 Implement cryptographic mechanisms to prevent unauthorized disclosure of CUI during transmission unless otherwise protected by alternative physical safeguards. , and 3.13.11 NIST SP 800-171 Rev. 2 Employ FIPS-validated cryptography when used to protect the confidentiality of CUI. .

In practice that means secure cookie flags, server-side session control, anti-CSRF measures, and careful browser behaviour. Weak session handling shows up fast in a serious review.

Public content and private files should not share the same path

One of the fastest ways to show weak security judgment is to treat every uploaded file like a public asset. A public event image, a downloadable brochure, and a member-uploaded document should not move through the same delivery path.

In CMMC-oriented design, information protection depends on deliberate handling. The relevant media protection controls are 3.8.1 NIST SP 800-171 Rev. 2 Protect system media containing CUI, both paper and digital. , 3.8.2 NIST SP 800-171 Rev. 2 Limit access to CUI on system media to authorized users. , 3.8.3 NIST SP 800-171 Rev. 2 Sanitize or destroy system media containing CUI before disposal or release for reuse. , and 3.8.9 NIST SP 800-171 Rev. 2 Protect the confidentiality of backup CUI at storage locations. . Sensitive documents need private storage patterns, controlled access, and time-limited retrieval where appropriate. Convenience should not decide visibility by default.

• It reduces overexposure of uploaded files.
• It supports safer handling of sensitive records.
• It prevents convenience shortcuts from turning into long-term risk.
• It creates a cleaner boundary between public web content and protected business data.

Secure communications are part of the baseline

Secure transport and browser protections are baseline, not optional hardening. That includes TLS, browser security headers, careful origin handling, and practical defences against common web attack patterns.

Here I map back to 3.13.8 NIST SP 800-171 Rev. 2 Implement cryptographic mechanisms to prevent unauthorized disclosure of CUI during transmission unless otherwise protected by alternative physical safeguards. and 3.13.11 NIST SP 800-171 Rev. 2 Employ FIPS-validated cryptography when used to protect the confidentiality of CUI. . If CUI is moving across a network boundary, the implementation should be boring and defensible.

NIST SP 800-171 3.13.11

“Employ FIPS-validated cryptography when used to protect the confidentiality of CUI.”

These controls are mostly invisible, which is why teams sometimes underinvest in them. They still separate a hardened platform from a fragile one.

Encryption should protect real workflows

I care less about claims like “we use encryption” than about where the encryption actually matters. Does it protect data in transit? Does it support secure partner exchanges? Does it stop protected information leaking through careless delivery flows?

This is another place where the real control references matter: 3.13.8 NIST SP 800-171 Rev. 2 Implement cryptographic mechanisms to prevent unauthorized disclosure of CUI during transmission unless otherwise protected by alternative physical safeguards. for transmission, 3.13.11 NIST SP 800-171 Rev. 2 Employ FIPS-validated cryptography when used to protect the confidentiality of CUI. for approved crypto, and 3.8.9 NIST SP 800-171 Rev. 2 Protect the confidentiality of backup CUI at storage locations. for backup confidentiality.

The strongest security decisions usually look unglamorous. They reduce exposure in real workflows, especially where data crosses trust boundaries.

Least privilege should exist in infrastructure too

Least privilege does not stop at the application layer. If the infrastructure behind the platform uses broad permissions, a well-designed app can still be undermined by a weak trust model underneath it.

I want narrowly scoped permissions for services, storage, and infrastructure components as well. If one component is misused, it should not automatically have the keys to everything else. The access-control family still matters here even when the implementation detail is IAM Acronym Identity and access management. The systems and policies used to define who can access what and under which conditions. policy rather than application role logic.

Privacy-aware design is part of security maturity

Some of the best security work never shows up in a dashboard. It shows up in quiet decisions about what data gets exposed, when, and to whom. Not every internal user should see every field just because the platform technically can expose it.

I want systems to sanitise, minimise, and filter based on context. Not all exposure comes from outside attackers. A lot of it comes from overbroad visibility, weak defaults, and convenience-driven design.

This is also where NIST SP 800-171A matters. It gives “assessment procedures and a methodology,” which matters when a team says a control exists but cannot show how it is examined, discussed, and tested. I read the 171A Rev. 3 page and then map it back to the control identifiers the DoD process still expects people to recognise.

Recovery matters too

Security is not only prevention. Recoverability matters: backups, restore paths, and infrastructure choices that assume failure is possible. A platform that cannot recover cleanly from outages, mistakes, or bad changes is not as secure as it looks.

For this part of the discussion, I would call out 3.8.9 NIST SP 800-171 Rev. 2 Protect the confidentiality of backup CUI at storage locations. for backup confidentiality and 3.12.4 NIST SP 800-171 Rev. 2 Develop, document, and update system security plans that describe system boundaries, operating environments, how security requirements are implemented, and relationships with or connections to other systems. for the system security plan that explains how the environment is actually put together.

That is one reason I tie security maturity to operational maturity. A system that can recover important records and restore continuity is in a much stronger position.

I see readiness as layered, not single-featured

No single capability makes a platform CMMC ready. Not login alone. Not encryption alone. Not cloud infrastructure alone. What matters is the overall pattern: disciplined thinking across identity, permissions, sessions, file handling, communications, privacy, infrastructure scoping, and recovery.

It also matters that the claims are anchored to real references. For a current Level 2 conversation, I want the latest NIST baseline, which is Rev. 3, clearly distinguished from the current CMMC Level 2 implementation language, which DoD still describes in terms of the 110 NIST SP 800-171 Rev. 2 requirements. Without that distinction, the conversation gets sloppy fast.

That foundation does not automatically equal compliance. But without it, compliance claims are weak.

Coming in part 2

In the next article, I will focus on the part many teams underestimate: audit logging, accountability, monitoring, evidence, and what the assessor can actually inspect. That is where technical security starts turning into assessable security.

If you want the broader systems context behind how I think about structured platforms, I touched adjacent problems in Why I usually pick SQL over NoSQL for military associations and The Hidden Admin Cost of Running an Association Across WordPress, Spreadsheets, and Plugins. If you want the raw scoring document behind the screenshots, I would still keep the DoD assessment methodology nearby while reading.