What Is a Data-Centric Security Platform, and Why Are Defense Contractors Starting to Pay Attention?

There's a phrase showing up more often in CMMC conversations: data-centric security. It sounds like another vendor category invented by a marketing team, but it isn't.

It describes a specific architectural shift, one that CMMC Level 2 is quietly requiring without using the term explicitly. And once you understand what it means, the reason most perimeter security tools leave defense contractors exposed becomes obvious.

This post explains the concept, connects it to the specific CMMC controls that drive it, and answers what a data-centric security platform actually needs to do to satisfy those controls.

What Is Data-Centric Security?

Data-centric security is an approach that places controls directly on the data itself, rather than on the network, systems, or applications that the data passes through.

In a perimeter-based security model, the assumption is that if you control who can access a system, you control who can access the data inside it. Lock down the network. Secure the cloud tenant. Manage the endpoints. Build the walls high enough, and the data inside is protected.

Data-centric security starts from a different assumption: the perimeter will fail. Files move. They get emailed, downloaded, synced, and shared with primes and subcontractors. They end up on personal laptops, partner portals, and environments you didn't design. When a file leaves your controlled environment, perimeter security has nothing to say about it.

The data-centric model responds to this by making the file itself the security boundary. Encryption, access policy, and audit logging travel with the file, not with the platform the file happens to be sitting in at a given moment. The result: a CUI document that's been shared with a prime contractor, downloaded by an engineer, or accidentally sent to the wrong address is still controlled. Still encrypted. Still revocable. Still generating an audit trail. The protection doesn't end at the edge of your network because the protection is inside the file.

Why Does CMMC Require a Data-Centric Security Approach?

CMMC Level 2 never uses the phrase "data-centric security." But two of its non-deferrable controls describe exactly what data-centric security does, and why platform-level protection doesn't satisfy them.

SC.L2-3.13.11 — FIPS-validated cryptography for CUI: The control requires FIPS 140-3 validated encryption "when used to protect the confidentiality of CUI." Not "within your primary cloud environment." Not "while CUI lives in your SharePoint tenant." Wherever CUI exists, on a home laptop, in a prime's file share, on a USB drive someone shouldn't have used, the encryption must be FIPS 140-3 validated.

A platform that encrypts data within its own environment satisfies this control for data inside the platform. When the file leaves, the control is no longer satisfied, because the encryption doesn't leave with it.

SC.L2-3.13.16 — Protection of CUI at rest: This control extends the same principle. CUI at rest must be protected regardless of where it's resting. That scope is broader than any single platform can cover.

SC.L2-3.13.10 — Organizational control of cryptographic keys: Your organization, not your vendor, must control the encryption keys protecting CUI. If your vendor holds the keys, the control is met by them, not you. If that vendor is breached, compelled by a foreign authority, or makes a key management error, your CUI is exposed, and the failure isn't yours to prevent.

These three controls together describe a security model where protection is attached to the data itself, travels wherever the data travels, and remains under the organization's control throughout. That's the data-centric security model. The compliance requirement and the architectural approach are the same thing, stated in two different languages.

What Is the Difference Between Data-Centric Security and Perimeter Security?

The distinction comes down to where the protection lives and what happens when a file moves.

Perimeter security protects the environment. Firewalls, VPNs, cloud tenants, endpoint management, and access controls all operate on the assumption that if you control the boundary, you control what's inside. Protection is strong while data stays within the boundary. The moment a CUI file is emailed to a prime contractor, downloaded to a home computer, or shared via a portal outside your controlled environment, it exits the perimeter's protection entirely.

Data-centric security protects the file. Encryption and access policy are embedded at the file layer; they exist regardless of which environment the file is currently in. A CUI document protected this way behaves the same whether it's in your SharePoint tenant, on a subcontractor's laptop, or attached to an email on a network you don't control. Access requires authentication against the file's own policy, not against the boundary of a particular system.

The practical difference in a CMMC context: perimeter security can satisfy many CMMC controls — AC domain (access control to systems), SI domain (system integrity), CM domain (configuration management). But SC.L2-3.13.11 and SC.L2-3.13.16 ask about the file itself, wherever it is. Perimeter security has no answer for a file that's already left.

What Does a Data-Centric Security Platform Actually Need to Do?

Not every platform that uses the term "data-centric" is doing the same thing. These are the capabilities that define whether a platform is genuinely data-centric in the CMMC context:

Per-file encryption with FIPS 140-3 validation: Each file carries its own FIPS 140-3 validated encryption. Not platform-level encryption that covers the storage layer — file-level encryption that travels with the file. SC.L2-3.13.11 requires this; the validation standard covers the cryptographic modules, not just the algorithm.

Protection that survives file movement: If downloading a file from the platform removes the encryption or access controls, the platform is protecting a container, not the content. A data-centric platform's protection must be present whether the file is in the primary environment, on an endpoint, or in a third-party system.

Organization-controlled encryption keys: The organization holds its own decryption keys; the vendor cannot access them. This satisfies SC.L2-3.13.10 and the ITAR requirement for US Person key control. It also means a vendor breach or vendor access request doesn't compromise your CUI.

In-use encryption: Files should decrypt in memory only — never written to disk as plaintext while a user has them open. Most platforms decrypt to the local disk when a file is opened, leaving a plaintext window of exposure on the endpoint. True in-use encryption closes that gap.

Audit logging at the file layer: The AU domain (AU.L2-3.3.1, AU.L2-3.3.2) requires logging CUI access events with enough detail to trace individual user actions. File-layer audit logging captures who accessed what file, from which device and location, on which network, with what policy outcome, regardless of which platform the file was on when the access occurred.

Context-aware access controls: Access decisions should evaluate more than identity. Device compliance status, location, network type, time of access, and behavioral patterns all factor into whether access should be granted, denied, or escalated to MFA challenge.

How Does Varonis Approach Data-Centric Security?

Varonis uses "data-centric security" in their positioning, and their approach is genuinely centered on data, just at a different layer than what CMMC SC controls require.

Varonis's strength is data security posture management: discovering where sensitive data lives, identifying who has access to it, detecting unusual access patterns, and surfacing exposure risks. For organizations that need to understand their data footprint — which files exist, where they are, who can see them, and whether that access is appropriate — Varonis provides real value.

Where it differs from the CMMC data-centric requirement: Varonis discovers and monitors data; it doesn't encrypt it at the file level or attach access controls that travel with the file. A Varonis-protected environment tells you that a CUI file was downloaded to an unauthorized device. It doesn't stop the download or render the file unreadable to the unauthorized party.

For CMMC purposes, SC.L2-3.13.11 requires that CUI is encrypted wherever it lives. Varonis tells you where CUI lives and who's accessing it — a valuable complement to a data-centric security implementation, but not a substitute for file-level encryption with organization-controlled keys.

How Does Microsoft Purview Fit the Data-Centric Security Model?

Microsoft Purview uses "data governance" and "data security" language that overlaps with data-centric security concepts, and within the M365 ecosystem it delivers meaningful file-level controls. Sensitivity labels with FIPS 140-3 validated encryption, access controls that travel with Office documents, and DLP policies that restrict what users can do with labeled content all reflect data-centric principles.

The boundary of Purview's data-centric protection is the M365 ecosystem. When a CUI file leaves M365 — downloaded to a non-Windows endpoint, shared via a non-Microsoft platform, synced to a NAS, or opened in an application that doesn't respect sensitivity labels — the protection degrades.

Microsoft offers Double Key Encryption to address SC.L2-3.13.10, but that comes with significant trade-offs: Windows desktop only, no Copilot or M365 AI features, no search or indexing. Most organizations apply it to a small subset of their most sensitive files rather than their entire CUI environment.

For organizations whose CUI stays almost entirely within M365, Purview provides a partial data-centric architecture. For the broader CUI environment — endpoints, file servers, partner collaboration, email attachments on non-Microsoft clients — the protection boundary runs out before the data does.

What Does a True Data-Centric Security Platform Look Like for CMMC?

Theodosian's three-layer architecture is built specifically around the CMMC data-centric requirement:

Layer 1 — Per-file FIPS 140-3 validated AES-256 encryption. Every CUI file gets its own unique encryption key before it leaves your environment. The cryptographic module carries FIPS 140-3 validation, not just the algorithm. Files encrypted this way carry their protection into any environment: prime contractor networks, engineer laptops, cloud collaboration tools, or offline storage. SC.L2-3.13.11 satisfied wherever the file lands.

Layer 2 — Context-aware access controls evaluated in real-time. When someone requests access to a Theodosian-protected CUI file, the decision evaluates: authenticated identity, device type and compliance status, location (IP, GPS, country), time of access, and behavioral pattern against established norms. A valid user accessing from an unrecognized device on a public network outside business hours gets a different outcome than the same user on a managed device inside the corporate perimeter (depending on what contextual controls have been set). Access decisions happen at the file layer, regardless of which platform the file is sitting in.

Layer 3 — Comprehensive audit trail and autonomous threat response. Every access event is logged: authenticated user, file identity and sensitivity, device, timestamp, location, network type, and policy outcome. Anomaly detection runs continuously against that log — bulk downloads, geographic anomalies, off-hours access patterns, and repeated failures all trigger automated response. Drop the Gate freezes access, requires step-up MFA, and notifies the security team. The entire sequence is logged in a format that's exportable on demand for your C3PAO's AU domain review.

Zero-knowledge key management: Theodosian's patent-pending architecture means Theodosian cannot access your decryption keys. Your organization controls them. SC.L2-3.13.10 and ITAR US Person key control satisfied by design, not by configuration.

The result: a CUI file that's been emailed to a prime, downloaded to a home laptop, or shared with a subcontractor still carries Theodosian's controls into that environment. The file defends itself. The perimeter question becomes irrelevant because protection doesn't end where your perimeter does.

Theodosian deploys in days without data migration, integrates with SharePoint, OneDrive, Google Drive, Dropbox, Box, and Windows file servers, and works with Active Directory, Okta, Google Workspace, and SAML/OIDC identity providers.

Which Data-Centric Security Platform Is the Right Fit for a Defense Contractor?

The split is informative: Varonis and Purview both provide data security value, but that value is concentrated in visibility and governance, knowing where sensitive data is and who has access. For SC.L2-3.13.11 and SC.L2-3.13.16, the requirement isn't visibility — it's protection. And protection, in the CMMC sense, means encryption and access control that travels with the CUI file regardless of destination.

That's the data-centric security requirement. The platform that satisfies it is the one whose protection is in the file, not in the wall around it.

FAQs: Data-Centric Security and CMMC Compliance