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're 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 don't ask permission, and they don't wait around for a platform to notice they exist; pleading ignorance later doesn't undo the exposure now.

CUI got its name and its rulebook from Executive Order 13556, signed in 2010, with the National Archives and Records Administration running the show. Before that order, agencies had cobbled together more than 100 different markings for sensitive-but-unclassified data, and the result was a total mess, with everyone using their own label, their own rules, their own filing cabinet with a different lock on it. 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 lot for STEM programs or anything with a defense-adjacent research angle.

Here's the part that trips people up: a platform doesn't get to decide whether it's handling CUI. The data decides, and the federal relationship decides. A vendor can be sitting on CUI right now with zero 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. Nobody sent a memo. Yet the obligation exists whether anyone read the fine print or not, which is exactly the kind of detail that turns into a bad Tuesday for a compliance officer three years later.

The three federal relationships that pull EdTech platforms into CUI scope

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

The first is the obvious one: 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, everyone knows where they stand. The whole arrangement is almost boring in how little anyone trips on this door.

The second door is the one that actually catches people, and it's the most common path for EdTech vendors specifically. 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, creating delays nobody budgeted for. The tools those researchers use are stuck in the exact same spot, inheriting a compliance burden nobody told them about until it was already due.

The third door 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. Institutions handling FTI under financial aid agreements sit inside that perimeter.

Here's the thing everyone gets backwards: they think the first door is the real risk and the other two are edge cases. It's the opposite. Direct federal contracts are rare for EdTech vendors and easy to spot when they happen. The subcontractor door and the FTI door are the ones quietly pulling in platforms that have never seen a federal signature, and they're far more common than the textbook case. Obligation follows the data, never the contract label. The right question for a platform operator isn't "do we contract with the government." It's whether the data moving through the system came from, or relates to, a federal program.

NIST SP 800-171 Rev 2 as the current operative standard and what its 110 controls actually require

NIST SP 800-171 is the rulebook for protecting CUI on systems the government doesn't 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 (not just one of the two), and audit logs that can't be quietly edited after the fact. Access has to run on least privilege, role-based, with a paper trail showing who approved what. There needs to be an incident response plan with real, defined steps, not a PDF nobody's opened since it was drafted. Media protection covers exports, disposal, and portable devices; system and communications protection covers boundary defense, monitoring, and session controls.

NIST doesn't tell you how to build any of this. It specifies the outcome and leaves the implementation up to the organization, which sounds generous right up until a platform unfamiliar with federal security language tries to figure out what "adequate" looks like in actual code. 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.

What NIST SP 800-171 Revision 3 changes and why EdTech platforms should prepare now even though it is not yet mandated

Revision 3 landed on May 14, 2024, and it is not mandatory yet. CMMC Level 2 assessments still run on Rev 2, and DoD hasn't set a hard transition date, though some advance notice is expected once one gets announced. None of that is a reason to sit on this. Waiting for the mandate before starting the work is the mistake, not a defensible strategy.

The control count actually drops, from 110 down to 97, though that shouldn't be read as looser rules; NIST consolidated overlapping requirements rather than cutting protections. Three new families show up: Planning, System and Services Acquisition, and Supply Chain Risk Management. All three have direct teeth for EdTech platforms running on third-party cloud infrastructure or plugged into 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 comes with more paperwork explaining the choices made. The whole framework moves closer to the NIST 800-53 moderate baseline too, which is good news for any platform already chasing FedRAMP Moderate.

The assessment guide got heavier as well. 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 digging through a lot more granular evidence than they used to.

The supply chain family, SR, deserves its own paragraph because it changes the most for EdTech specifically. It formalizes the obligation to vet and manage the security posture of vendors and subprocessors, not just the platform's own house. If a platform runs on somebody else's cloud, or plugs into a third-party API for research data handling, SR means that relationship now needs documented oversight. Platforms with complicated, multi-tenant architectures or a lot of third-party integrations should start mapping to Rev 3 now, because whenever the transition window lands, it'll be short, and everyone will be scrambling for the same assessors at the same time.

How CMMC 2.0 converts NIST controls into an enforceable certification requirement — and where the July 2026 suspension leaves things

CMMC 2.0 exists because DoD got tired of taking contractors at their word. Self-certification wasn't cutting it, so the finalized program requires contractors handling CUI to get 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 allowed. Level 2 is the one 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 need the full third-party certification. Level 3 is reserved for especially sensitive CUI and carries the highest bar of the three.

The rollout was supposed to happen in phases. Phase 1 required Level 1 or Level 2 self-assessment as a condition of getting a contract awarded at all. Phase 2 was set to follow, the point where self-attestation would stop being good enough for most Level 2 contractors.

Then, DoD paused the third-party assessment requirement. Worth being precise about what that pause actually covers: contractors are still fully bound by DFARS 252.204-7012 to protect CUI and report incidents. The suspension removes the certification gate, but it does not touch the underlying obligation to protect the data itself, which is exactly the kind of distinction that lets a compliance program quietly rot for a year.

Treat the pause as a window, not a pardon. Any EdTech platform reading the suspension as permission to shelve compliance work is setting up its own scramble for whenever the requirement comes back online, and university prime contractors stay on the hook for subcontractor compliance the entire time the pause runs. The DFARS clause never went anywhere: incident reporting, system security plans, and CUI safeguarding requirements are contractually live right now, suspension or no suspension.

The proposed FAR CUI rule and how it would extend obligations beyond defense contractors to all federal vendors

Everything above has been a DoD story, and that's about to stop being true.

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 sits in the queue awaiting finalization.

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

There's real money behind enforcement here. 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 isn't waiting around either, having moved to set CUI protection requirements for its own contractors independent of whatever happens with the FAR rule.

Whether the FAR rule finalizes exactly as written or gets revised again, the direction isn't in question. 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, rule or no rule.

Where higher education institutions actually stand on compliance — and what that means for the platforms they use

Right now, formal CUI security obligations 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 ed as a sector yet, outside those specific lanes.

That said, most institutions aren't sleepwalking through this. Available survey data from EDUCAUSE indicates that a meaningful share of institutions rate SP 800-171 compliance a high or moderate priority, which reads as engaged rather than panicked. Nobody's treating this as background noise, but almost nobody's treating it as a five-alarm fire either.

Governance is the part that gets messy, and here's where the real risk for EdTech vendors actually sits. Per that same EDUCAUSE survey, the CISO commonly leads compliance efforts, often as the largest single responsible group, but responsibility is scattered across IT security, institutional leadership, and governance functions. No single person owns this at most schools, and that's the actual problem: the administrator who signs off on a platform contract is rarely the same person who'd be held accountable if that platform failed a CUI audit. A vendor's own compliance posture has to fill that gap, because nobody upstream is going to fill it first.

Institutions name the same barriers over and over: not enough staff, competing priorities eating up attention, and federal guidance that keeps shifting under their feet. a recurring theme across research institutions is that institution-wide compliance is difficult given how decentralized research environments actually are, and that's not an outlier complaint; it's closer to the standard condition. Researchers commonly find out about CUI requirements only once the contract's already signed and the clock has already started.

Not every school is stuck there, though. 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's a plan-based model other institutions could copy, and it's worth an EdTech vendor knowing which of its university customers have built something similar and which haven't gotten there yet.

The takeaway here is blunt, and it's the one most vendors resist hearing: don't assume the university customer has this handled upstream. A lot of them don't, structurally can't, and won't for a while yet. Betting a platform's compliance posture on the hope that the school already figured this out is the single most common mistake in this whole ecosystem. Platforms need to show their own controls, independent of whatever compliance posture the institution claims on paper.

The specific operational controls an EdTech research platform must implement to handle CUI

Before any control gets built, the platform has to draw a line: which systems, which components, which data flows actually count as in scope for CUI. That boundary decides what gets protected, what gets audited, and what an assessor opens first.

Everything gets written down in a System Security Plan, or SSP, laying out the system boundary, every applicable control, the implementation status of each one, and who's responsible for what. The SSP is the document a DFARS assessment or a C3PAO audit reads before anything else, so a vague SSP is basically an invitation to dig deeper.

Access control starts with multi-factor authentication on every account that touches CUI, no exceptions for convenience. Permissions run on least privilege and role-based assignment, with no standing elevated access sitting around unused and forgotten. User authorization needs a documented process, and access needs regular review, not a one-time setup nobody revisits again.

Encryption has two halves. CUI at rest needs FIPS 140-2 or 140-3 validated encryption modules, while CUI in transit needs TLS 1.2 at minimum, TLS 1.3 where possible. Key management procedures belong in the SSP, spelled out, never just assumed.

Audit logging needs to be tamper-evident, covering every access to CUI-touching systems. A log that can be quietly edited after the fact isn't a log any assessor will accept, and it isn't one that protects the institution or the platform when something actually goes wrong.