Controlled Unclassified Information Obligations for EdTech Research Platforms

Federally funded research runs through EdTech platforms every day: learning management systems, data repositories, collaboration tools. Most of those platforms have no idea they are handling Controlled Unclassified Information, or CUI, a legal category of sensitive government data that sits below classified but well above public. The obligations tied to CUI do not ask permission, and they do not wait around for a platform to notice they exist. Pleading ignorance later does not undo the exposure.

CUI got its name and its rulebook from Executive Order 13556, signed in 2010, with the National Archives and Records Administration running the program. Before that order, agencies had cobbled together more than 100 different markings for sensitive-but-unclassified data, producing a fragmented system where every agency used its own label, its own rules, and its own protection requirements. NARA's job was to take that patchwork and turn it into one system. The CUI registry is the result: a single, government-wide list of categories that count as protected.

Four categories show up again and again in EdTech and research platforms specifically. Federal Tax Information, or FTI, comes up constantly in financial aid workflows tied to SAIG agreements. Research data collected or used under federal grants and contracts is its own category. Personally identifiable information handled on behalf of a federal agency counts too, and export-controlled technical data matters a great deal for STEM programs or anything with a defense-adjacent research angle.

A platform does not get to decide whether it is handling CUI. The data decides, and the federal relationship decides. A vendor can be sitting on CUI with no direct contract with any federal agency, simply because the university it works with is a prime contractor and the vendor's work touches covered data somewhere downstream. The obligation exists whether anyone read the fine print or not, which is exactly the kind of detail that turns into a serious compliance problem years later.

Three Federal Relationships That Create CUI Scope

Three paths lead into CUI territory, and only one of them looks like what most people expect.

The first is a direct federal contract or grant, where the platform is named as a contractor or subcontractor on a Department of Defense or civilian agency award that involves CUI. Everyone signs a contract, everyone reads the clauses, and everyone knows where they stand. This path is almost boring in how rarely anyone stumbles on it.

The second path is the one that actually catches people, and it is the most common route for EdTech vendors. A university holds the prime award, and the EdTech vendor sits underneath it as a subcontractor. Federal acquisition rules require universities, as primes, to flow down CUI protection obligations to subcontractors whose work touches covered defense information. The university stays on the hook for enforcement, but the vendor inherits the obligation whether or not anyone explained it clearly at signing. This timing problem is common across research institutions: compliance requirements surface after the contract is already awarded, and the tools those researchers use inherit a compliance burden nobody communicated until it was already due.

The third path runs through federal student aid. Institutions sharing Federal Tax Information as part of financial aid processing fall under NARA's stated position that agencies sharing CUI with colleges and universities should extend the full CUI program, including NIST SP 800-171 compliance, to those institutions.

Direct federal contracts are rare for EdTech vendors and easy to spot when they happen. The subcontractor path and the FTI path are the ones quietly pulling in platforms that have never seen a federal signature, and they are far more common than the textbook case. Obligation follows the data, not the contract label. The right question for a platform operator is not whether it contracts with the government. The question is whether the data moving through the system came from, or relates to, a federal program.

What NIST SP 800-171 Rev 2 Actually Requires

NIST SP 800-171 is the rulebook for protecting CUI on systems the government does not own. It applies based on what the system does, not who owns it, so a privately built EdTech platform is exactly as in-scope as a government data center once CUI starts flowing through it.

Revision 2 remains the operative version, and current DFARS self-assessments and CMMC Level 2 requirements are still built on it. It organizes protection into 14 control families and 110 specific security requirements, covering access control, training, audit logging, configuration management, identity verification, incident response, maintenance, media handling, personnel security, physical security, risk assessment, security assessment, system protection, and information integrity.

Translated into what an EdTech platform actually has to build: multi-factor authentication on every system that touches CUI, encryption for CUI at rest and in transit, and audit logs that cannot be edited after the fact. Access has to run on least privilege and role-based assignment, with a paper trail showing who approved what. There needs to be an incident response plan with real, defined steps. Media protection covers exports, disposal, and portable devices, while system and communications protection covers boundary defense, monitoring, and session controls.

NIST specifies the outcome and leaves implementation up to the organization. Self-assessment produces a score based on the 110 controls, and DoD contractors are required to report that score into a government tracking system where it is visible to those with a reason to look.

Why Rev 3 Demands Preparation Now

Revision 3 landed on May 14, 2024, and it is not mandatory yet. CMMC Level 2 assessments still run on Rev 2, and DoD has not set a hard transition date. Waiting for the mandate before starting the work is not a defensible strategy.

The control count drops from 110 down to 97, though that should not be read as looser rules. NIST consolidated overlapping requirements rather than cutting protections. Three new families appear: Planning, System and Services Acquisition, and Supply Chain Risk Management. All three have direct implications for EdTech platforms running on third-party cloud infrastructure or connected to outside research tools. Rev 3 also expands the use of organizationally defined parameters, giving more room to tailor controls to a specific environment, but that flexibility requires documented justification for every choice made. The framework also moves closer to the NIST 800-53 moderate baseline, which is useful for any platform already pursuing FedRAMP Moderate.

The assessment guide grew substantially. SP 800-171A Rev 3 now runs 422 determination statements, up from 320 under Rev 2, a jump of roughly 32%. Third-party assessors will be reviewing far more granular evidence than they did previously.

The supply chain family, SR, changes the most for EdTech platforms. It formalizes the obligation to vet and manage the security posture of vendors and subprocessors, not just the platform's own infrastructure. If a platform runs on a third-party cloud or connects to a third-party API for research data handling, that relationship now requires documented oversight. Platforms with multi-tenant architectures or many third-party integrations should begin mapping to Rev 3 now, because whenever the transition window arrives, it will be short and assessor availability will be constrained.

CMMC 2.0 Enforcement After the July 2026 Pause

CMMC 2.0 exists because DoD required an alternative to contractor self-certification. The finalized program requires contractors handling CUI to be certified by an accredited outside assessor.

There are three levels. Level 1 covers Federal Contract Information only, with 15 basic practices and annual self-assessment still permitted. Level 2 is the level that matters for CUI, aligned to the full 110 controls of NIST SP 800-171 Rev 2. DoD estimated roughly 4,000 contractors could self-certify at this level, while more than 76,000 would require full third-party certification. Level 3 is reserved for especially sensitive CUI and carries the highest bar.

The rollout was designed in phases. Phase 1 required Level 1 or Level 2 self-assessment as a condition of contract award. Phase 2 was set to follow, the point where self-attestation would stop being sufficient for most Level 2 contractors.

DoD then paused the third-party assessment requirement. Contractors are still fully bound by DFARS 252.204-7012 to protect CUI and report incidents. The suspension removes the certification gate but does not affect the underlying obligation to protect the data itself, which is the kind of distinction that allows a compliance program to quietly deteriorate over time.

Any EdTech platform reading the suspension as permission to shelve compliance work is creating its own scramble for whenever the requirement returns. University prime contractors remain responsible for subcontractor compliance throughout the entire period the pause runs. The DFARS clause was never suspended: incident reporting, system security plans, and CUI safeguarding requirements are contractually active right now.

The FAR CUI Rule Expands Beyond Defense

On January 15, 2025, the FAR Council published a proposed rule that would impose CUI safeguarding, training, and incident reporting requirements on every federal contractor and subcontractor handling CUI, not just defense-related ones. On June 23, 2026, the Council re-proposed the rule under Executive Order 14275, "Restoring Common Sense to Federal Procurement." The comment period closed July 23, 2026, and the rule now awaits finalization.

Several provisions stand out. The original draft imposed strict incident-reporting timelines that drew significant pushback. The June 2026 revision softened some reporting triggers, though the core rapid-reporting expectation for confirmed incidents remains. A cloud provider requirement is also included: if a contractor stores, processes, or transmits CUI through a cloud service, that cloud provider must meet federal security baseline requirements. This applies directly to any EdTech SaaS product running on commercial cloud infrastructure. Flow-down to subcontractors is explicit in the rule's text, meaning universities and research institutions working with civilian agencies would be required to pass these obligations on to their EdTech vendors.

There is real enforcement behind this direction. The Department of Justice has recovered more than $80 million in cybersecurity-related False Claims Act settlements since October 2021, and a finalized FAR rule would sharpen that enforcement by giving agencies one standardized definition of what required controls actually means. The General Services Administration has already moved to set CUI protection requirements for its own contractors, independent of whatever happens with the broader FAR rule.

CUI obligations are moving out of the defense-only lane and into the entire federal contractor ecosystem. Any platform serving a federally funded institution is already standing inside that perimeter.

Where Higher Education Actually Stands on Compliance

Formal CUI security obligations currently apply to institutions acting as contractors or subcontractors on DoD projects involving CUI, plus certain NIH research projects involving genomic data. No broader mandate covers higher education as a sector yet, outside those specific lanes.

Available survey data from EDUCAUSE indicates that a meaningful share of institutions rate SP 800-171 compliance a high or moderate priority, reflecting genuine engagement rather than alarm. Governance is where things get complicated, and this is where the real risk for EdTech vendors sits. Per that same EDUCAUSE survey, the CISO commonly leads compliance efforts, but responsibility is distributed across IT security, institutional leadership, and governance functions. No single person owns this at most schools. The administrator who signs off on a platform contract is rarely the same person who would be held accountable if that platform failed a CUI audit. A vendor's own compliance posture has to fill that gap, because no one upstream will fill it first.

Institutions consistently identify the same barriers: insufficient staff, competing priorities, and federal guidance that keeps changing. Institution-wide compliance is difficult given how decentralized research environments actually are, and that is not an outlier complaint. Researchers commonly learn about CUI requirements only after the contract is already signed and the clock has already started.

Some institutions have moved to require formal technology control plans for any CUI used, stored, or transmitted on their systems, covering both research and other contractual work. That model is worth understanding, both because other institutions could replicate it and because an EdTech vendor should know which of its university customers have built something similar and which have not.

The practical conclusion is blunt: platforms should not assume the university customer has this handled upstream. Many institutions do not, and structurally cannot for some time yet. Betting a platform's compliance posture on the assumption that the school already resolved this is the single most common mistake in this ecosystem. Platforms need to demonstrate their own controls, independent of whatever compliance posture the institution claims on paper.

Operational Controls EdTech Platforms Must Actually Implement

Before any control gets built, the platform has to define a boundary: which systems, which components, and which data flows actually fall within scope for CUI. That boundary determines what gets protected, what gets audited, and what an assessor examines first.

All of this gets documented in a System Security Plan, or SSP, which lays out the system boundary, every applicable control, the implementation status of each one, and who is responsible for what. The SSP is the document a DFARS assessment or a C3PAO audit reads before anything else, so an incomplete SSP functions as an invitation to dig deeper into every area it fails to address clearly.

Access control starts with multi-factor authentication on every account that touches CUI, with no exceptions made for convenience. Permissions run on least privilege and role-based assignment, with no standing elevated access left unused and unreviewed. User authorization requires a documented process, and access levels need regular review rather than a one-time setup that nobody revisits.

Encryption has two halves. CUI at rest requires FIPS 140-2 or 140-3 validated encryption modules, while CUI in transit requires TLS 1.2 at minimum and TLS 1.3 where possible. Key management procedures belong in the SSP, documented explicitly rather than assumed.

Audit logging must be tamper-evident and must cover every access to CUI-touching systems. A log that can be edited after the fact will not satisfy an assessor and will not protect the institution or the platform when something actually goes wrong.