NSPM-33 compliance: where biodefense research security programs actually fail
Julian ThorneApril 29, 2026
Key takeaways
NSPM-33 compliance failures are almost never about missing policy documents — they are about technical controls that were documented but never validated, and security measures that describe intended configurations rather than actual ones.
International collaboration agreements that receive legal sign-off routinely fail to address the technical data flows they govern: access controls, encryption key management, and data residency at the implementation layer are frequently inconsistent with what the signed agreement describes.
Insider threat programs required under NSPM-33 are typically assessed for existence, not operational effectiveness. A program that monitors access logs without behavioral baselining or anomaly detection does not meet the intent of the requirement, regardless of what the policy document says.
Cloud storage misconfigurations — specifically, reliance on provider-default encryption without customer-managed key controls — represent the most commonly observed technical gap in biodefense research environments assessed against NSPM-33.
Research institutions that scope NSPM-33 controls to their primary research networks routinely miss computational analysis environments, bioinformatics pipelines, and collaboration platforms that process or transmit data covered by the memorandum.
TL;DR
NSPM-33 is a national security directive aimed at protecting federally funded research from foreign interference and data theft. The compliance failures that show up in assessments are not about institutions ignoring the requirement — most have policies, training programs, and signed collaboration agreements. The failures are about the gap between documented controls and operational reality: encryption configurations that don''t match policy, insider threat programs that log activity without analyzing it, and scoping decisions that exclude the systems where sensitive data actually moves. The policy layer is mostly fine. The technical layer is where the exposure lives.
What the assessment found that the legal review missed
A research institution with NIH funding for biodefense work had completed a thorough legal review of its international collaboration agreements before engaging us. Outside counsel had reviewed each agreement. The institution''s research security officer had signed off. The agreements specified data handling requirements, access restrictions, and security standards for each collaborating institution. From a documentation standpoint, the program was well-constructed.
When we examined the technical implementation, the picture was different. The primary data sharing mechanism with one overseas collaborator was an SFTP server that the research IT team had configured three years earlier. The server was running a version of the underlying software with known vulnerabilities. The access credentials used by the collaborating institution had not been rotated since the agreement was executed. The transfer logs were being written to a directory that the collaborating institution''s access account could also read — meaning the external party could see the metadata of every file transfer across the entire collaboration, not just their own.
The legal agreement said the collaborating institution had access to specific datasets. The technical implementation gave them access to considerably more. Nobody had compared the two. The legal review established what was permitted. Nobody had verified that the technical configuration enforced those boundaries. That gap is where NSPM-33 compliance actually lives — not in the agreements, but in the correspondence between what the agreements say and what the systems do.
What NSPM-33 requires and where the audit methodology misses it
National Security Presidential Memorandum 33 was issued in January 2021 and directs federal agencies to strengthen protections for United States government-supported research and development against foreign government interference and theft. The memorandum applies to research institutions receiving federal funding and establishes requirements across several domains: research security programs, foreign talent program disclosures, export controls, cybersecurity, and insider threat programs.
The cybersecurity requirements under NSPM-33 are not written as prescriptive technical controls. They direct institutions to implement security measures appropriate to the sensitivity of the research, consistent with existing federal cybersecurity frameworks. This gives institutions flexibility and creates an audit challenge: compliance cannot be verified by checking whether specific controls are present. It requires assessing whether the controls that are present are adequate given the threat environment and the sensitivity of the research.
Most compliance reviews of NSPM-33 programs focus on documentation: Is there a research security plan? Are collaboration agreements in place? Has the insider threat program been established? These are necessary questions. They are not sufficient ones. A research security plan that describes data encryption without specifying the implementation does not tell you whether the data is actually encrypted with appropriate methods. An insider threat program document that outlines monitoring requirements does not tell you whether the monitoring is running, what it is looking for, or whether anyone is reviewing the output.
The gap between documented compliance and operational compliance is a general problem across security frameworks, but it is particularly acute under NSPM-33 because the threat model is sophisticated. Foreign intelligence services targeting biodefense research are not looking for unlocked doors. They are looking for the gaps between what the policy says and what the system does.
Example
One institution had a data classification policy that designated biodefense research data as sensitive and required encryption at rest using AES-256. The AWS S3 buckets containing the primary research datasets were configured with server-side encryption enabled. The CISO considered this compliant. What the configuration actually used was SSE-S3 — Amazon''s default server-side encryption where AWS manages the encryption keys. Under SSE-S3, Amazon holds the key material. Under the institution''s policy intent — protecting sensitive government-funded research from unauthorized access — the control is inadequate because the key management is outside the institution''s control. The encryption checkbox was checked. The key management question had never been asked.
Bioinformatics pipelines used for genomic analysis of biodefense-relevant organisms present a scoping problem that standard IT security assessments miss. These pipelines — frequently built on workflow managers like Nextflow or Snakemake — process sensitive biological data through computational steps that run across distributed infrastructure. The pipeline itself is software, and like all software it can be misconfigured, can contain vulnerabilities, and can be targeted. But because it is not a traditional IT system, it frequently falls outside the scope of vulnerability assessments and security monitoring. The intermediate data produced by analysis steps — partial genomic assemblies, alignment files, annotated sequences — may be more sensitive than the raw input data, and its handling is often governed by no specific control.
What we find in NSPM-33 assessments
Assessment base: Vulnox assessment data, 2024-2025, federally funded research institution and biodefense program environments
Insider threat programs that satisfy the policy requirement without meeting the operational intent
NSPM-33 requires institutions to establish insider threat programs capable of detecting, deterring, and mitigating insider threats to research security. In practice, most institutions have created programs that document the requirement, designate a responsible official, and describe the monitoring activities that should occur. The monitoring itself is frequently absent or incomplete. Institutions that have deployed SIEM platforms often point to log ingestion as evidence that monitoring is operational. Log ingestion and behavioral monitoring are not the same thing. A SIEM receiving authentication logs without anomaly detection rules configured for research environment user behavior is a log repository, not an insider threat detection capability.
An insider threat program that exists on paper but does not operate in practice provides no protection against the threat it was designed to address. More significantly, it creates a documented assurance to oversight bodies — and to the institution itself — that a capability exists when it does not. The risk is not just the insider threat itself but the false confidence that active monitoring provides.
International collaboration technical controls that lag behind the legal agreements governing them
Every institution we have assessed with international collaboration components under NSPM-33 has executed formal agreements reviewed by legal counsel. In a consistent pattern, the technical implementation of data sharing under those agreements does not reflect the controls the agreements require. Access permissions are broader than the agreement specifies. Encryption requirements described in the agreement are implemented partially or inconsistently. Audit logging of cross-border data transfers exists in some systems and is absent in others. The legal team that reviewed the agreement and the IT team that configured the sharing mechanism are typically different people who did not compare notes.
The agreement creates a documented obligation. The technical configuration determines whether that obligation is honored. When the two diverge, the institution is exposed to both the underlying security risk — data accessible beyond what was intended — and the compliance risk of operating outside the terms of its own signed agreements.
Computational analysis environments excluded from the security scope applied to primary research data
Institutions typically scope their NSPM-33 technical controls around the systems where primary research data is stored: the genomic database, the laboratory information management system, the secure file repository. The computational environments used to analyze that data — HPC clusters, cloud-based analysis platforms, containerized bioinformatics workflows — are frequently treated as research infrastructure rather than security-relevant systems. Sensitive data flows through these environments during analysis, intermediate outputs are stored in them, and they often connect to external resources for reference databases and tool updates. None of that is captured by controls scoped only to primary storage.
An attacker who cannot reach the primary research data repository may be able to reach the analysis pipeline that processes it. The sensitivity of the intermediate data produced during analysis is often equivalent to the source data. Excluding the analysis environment from security scope is not a risk-based decision — it is a scoping convention that does not reflect where data actually exists during the research workflow.
What standard NSPM-33 compliance reviews do not catch
Metadata exposure in collaborative research environments
NSPM-33 addresses protection of research data and intellectual property. Compliance reviews focus on the data itself — are the files encrypted, are the access controls appropriate, are the transfers logged. What they consistently miss is the metadata layer: file names that reveal research subjects, directory structures that expose project organization, transfer logs that show frequency and volume of data movement, and hash values that allow a recipient to verify whether files have changed. In collaborative environments where partial access is intended, metadata exposure can provide a foreign adversary with significant insight into research direction and progress without requiring access to the protected data itself.
Software supply chain for research tools
Biodefense research environments use specialized scientific software — sequence analysis tools, molecular modeling applications, laboratory data management systems. This software is typically sourced from academic repositories, commercial vendors, or open-source communities. The supply chain security of these tools is rarely assessed. A dependency in a widely used bioinformatics package with a compromised update represents an attack vector that bypasses perimeter controls entirely, because the malicious code arrives as a legitimate software update through a trusted channel. NSPM-33 compliance reviews do not typically include software supply chain analysis for research tools.
Alumni and former collaborator access persistence
Research institutions have high personnel turnover: graduate students complete degrees, postdoctoral researchers move to other institutions, visiting scientists return home. Access deprovisioning in research environments is frequently informal — dependent on the departing individual notifying someone, or on periodic manual reviews that occur on academic timelines rather than security timelines. Former collaborators — including international ones — retain active credentials to shared analysis platforms, collaborative repositories, and communication tools months or years after their formal affiliation ends. This is not unique to research environments but is more pronounced in them because the culture treats access as a collegial courtesy rather than a security-relevant permission.
Where NSPM-33 enforcement and exposure are heading
Within three years, at least one federally funded research institution will face grant termination or suspension specifically linked to NSPM-33 technical control failures — not disclosure violations — establishing that the cybersecurity requirements carry enforcement consequences independent of the foreign talent disclosure provisions.
Current enforcement attention under NSPM-33 has focused primarily on foreign talent disclosure failures: researchers who did not disclose foreign appointments, grants, or affiliations. The technical security requirements have received less enforcement attention despite being equally central to the memorandum''s intent. As oversight bodies mature their review processes and as breaches involving biodefense research data accumulate, the technical control requirements will attract enforcement scrutiny. The first case on this theory will change how institutions prioritize the cybersecurity provisions.
Confidence: mediumNo grant action specifically citing NSPM-33 technical control failures by end of 2027 would indicate the timing prediction was wrong.Bioinformatics pipeline security will become a distinct compliance domain within federal research security frameworks within four years, with specific control requirements for computational analysis environments separate from data storage and transmission requirements.
The current framework treats data security holistically without distinguishing between storage, transmission, and processing environments. As the research community''s understanding of where sensitive data exists during analysis matures — and as incidents involving computational infrastructure rather than primary data storage accumulate — oversight bodies will recognize that general data security requirements are insufficient for analysis pipeline environments. The specificity gap is already visible to anyone who has assessed a research environment technically.
Confidence: lowNo federal research security guidance specifically addressing computational analysis environment controls by end of 2028 would indicate the direction was wrong or the timeline too aggressive.
The foreign interference framing obscures the more common threat
NSPM-33 was written in response to a specific threat: foreign government programs, primarily but not exclusively Chinese, systematically targeting US government-funded research. That threat is real and the policy response is warranted. But the framing has a side effect — it leads institutions to think about NSPM-33 compliance primarily as a counterintelligence problem rather than a security operations problem.
The practical result is that compliance programs focus on the foreign disclosure requirements — who has foreign appointments, what foreign grants were received, what international collaborations exist — and treat the cybersecurity provisions as secondary. The assumption is that if the known foreign connections are disclosed and managed, the exposure is addressed.
That assumption is wrong in two directions. First, the threat is not limited to disclosed, known collaborations. Foreign intelligence targeting does not announce itself. The access path is often through a vulnerability in the research infrastructure rather than through a disclosed collaboration. Second, the most common source of sensitive data exposure in research environments is not sophisticated foreign intelligence targeting — it is basic misconfigurations, stale access, and controls that were never validated. These failures do not require a sophisticated adversary to exploit.
A compliance program that focuses on the counterintelligence dimension and neglects the basic security operations dimension is optimized for the wrong failure mode.
Counterargument
The counterargument is that NSPM-33 was specifically designed for the foreign interference threat, and a compliance program should be optimized for the stated risk. General cybersecurity hygiene is addressed by other frameworks. That argument has merit as a framework design question. As an operational matter, the security failures that lead to successful foreign intelligence collection against research institutions start with the same basic vulnerabilities that any attacker exploits.
One action this week
Identify three systems in your research environment that process or store biodefense-relevant data but are not explicitly listed in your current NSPM-33 security scope. Look beyond primary data repositories: the analysis cluster, the collaboration platform, the data transfer mechanism to international partners. For each one, answer whether the access controls, encryption configuration, and audit logging that your security plan describes are actually implemented and operating. If the answer requires checking rather than knowing, that is the finding.
Further Reading
Gap Analysis
framework gap analysisVulnerability Assessment
biological risk vulnerability assessmentUS federal cybersecurity frameworks: the complete guide to all 37 mandates
NSPM-33 compliance requirementsNIST SP 800-30 Risk Assessment Guide
NIST risk assessment guideNVD Vulnerabilities Database
national vulnerability databaseOWASP Web Security Testing Guide
OWASP security testing guide
Frequently Asked Questions
What does NSPM-33 require for cybersecurity controls on biodefense research data?
NSPM-33 requires research institutions to implement cybersecurity measures appropriate to the sensitivity of the research, consistent with federal cybersecurity frameworks. It does not specify prescriptive technical controls. In practice, this means institutions must assess the sensitivity of their research, identify the systems that process and store relevant data, and implement controls — including encryption, access management, monitoring, and incident response — commensurate with the threat environment. The compliance challenge is that adequacy is assessed against the threat model, not against a checklist.
Why is legal sign-off on international collaboration agreements not sufficient for NSPM-33 compliance?
Legal review of collaboration agreements establishes what is permitted and required under the agreement. It does not verify whether the technical implementation of data sharing actually enforces those terms. In assessments of institutions with signed, legally reviewed agreements, the technical configuration of data transfer mechanisms, access controls, and encryption consistently diverges from what the agreement specifies. The agreement creates the obligation. The technical configuration determines whether it is honored. Both need to be assessed.
What makes an insider threat program operationally effective under NSPM-33 versus compliant on paper?
An operationally effective insider threat program does three things a paper program typically does not: it monitors actual user behavior against a baseline established for that environment, it generates alerts on deviations that are reviewed by someone with authority to act, and it covers the full population of users with access to sensitive data — including research collaborators, service accounts, and system administrators, not just permanent staff. Log ingestion without behavioral analysis is not detection capability. A policy document that describes monitoring without evidence that the monitoring is running is not a program.
Which systems should be in scope for NSPM-33 technical controls that institutions typically miss?
The most commonly missed systems are computational analysis environments: HPC clusters, cloud-based analysis platforms, containerized bioinformatics workflows, and scientific software pipelines. These systems process sensitive research data during analysis, produce intermediate outputs that may be as sensitive as the source data, and often connect to external resources. They are typically treated as research infrastructure and excluded from IT security scope. Any system through which data covered by NSPM-33 passes during its lifecycle should be in scope for the relevant technical controls.
What is the most common technical misconfiguration found in biodefense research environments assessed against NSPM-33?
Reliance on provider-managed encryption for cloud storage without customer-managed key controls. Research institutions that store data on AWS S3, Azure Blob Storage, or equivalent platforms frequently use the provider's default server-side encryption, where the provider manages the key material. This satisfies a surface-level encryption requirement but does not give the institution control over key access, rotation, or revocation. Under the threat model NSPM-33 addresses — sophisticated adversaries with potential access to cloud provider infrastructure — provider-managed keys are an inadequate control for sensitive research data.
How should research institutions scope their NSPM-33 security assessment?
Start by mapping every system through which biodefense-relevant data flows during its lifecycle — from collection through analysis, storage, and sharing. This includes primary research data repositories, laboratory information management systems, computational analysis environments, data transfer mechanisms, collaboration platforms, and communication tools used to discuss research. Then assess whether the controls your security plan describes are implemented and operating in each of those systems. Scoping based on where data is stored rather than where it travels during research workflows is the most common reason assessments miss significant exposure.
Related Articles
GovRAMP Moderate authorization: why the Significant Change Request process catches providers off guard
GovRAMP Moderate is the first tier where you need a government sponsor, annual 3PAO reassessment, and a Significant Change Request process that can pause normal product releases for months. Most providers who stall post-authorization were not prepared for what maintaining Moderate status actually costs operationally.
GovRAMP Low+ authorization: the impact level that punishes providers who get the CUI boundary wrong
GovRAMP Low+ is where providers handling limited Controlled Unclassified Information land — or discover they should not be there. The defining failure is not a missing control. It is a CUI boundary that was drawn before anyone asked what data the government actually sends through the system.
GovRAMP High authorization: why FIPS-validated crypto and personnel security controls catch providers off guard
GovRAMP High is where cloud providers discover that having strong encryption is not the same as having FIPS 140-2 validated encryption — and that distinction alone has derailed authorizations from vendors who passed every other control family. The architectural constraints at High are qualitatively different from every lower tier.
Ready to Secure Your Digital Assets?
Get a comprehensive vulnerability assessment for your website today.