NSF 25-531: Cybersecurity Innovation for Cyberinfrastructure (CICI)

NSF 25-531: Cybersecurity Innovation for Cyberinfrastructure (CICI)

The U.S. National Science Foundation’s Cybersecurity Innovation for Cyberinfrastructure program (CICI) is an active solicitation for institutions and research teams that can improve how science is protected and how scientific computing environments stay usable, scalable, and trustworthy. The program is focused on the infrastructure that supports modern discovery: secure computation, reliable scientific workflows, collaborative data environments, and AI-ready scientific datasets.

This is a strong 2026/2027-cycle opportunity because the solicitation page explicitly shows recurring deadlines. It is not a one-off, single-deadline award. Proposals are part of a structured NSF competition framework that advances annually with a published cycle and a fixed annual “third Wednesday in January” closure pattern after its recent cycle dates.

Key details at a glance

What CICI funds and why this is not a generic cyber grant

CICI is explicitly about scientific cyberinfrastructure, not a broad cybersecurity fund for any organization. The solicitation makes a practical distinction: it supports work that benefits the scientific enterprise and its discovery infrastructure. NSF separates this from general cybersecurity research and emphasizes practical security for research environments.

At a high level, the program exists for teams proposing applied work that improves:

• security and privacy in scientific computing
• resilience and robustness of distributed research systems
• reproducibility of workflows
• usability of security mechanisms for real scientists, not only security experts
• dataset integrity and provenance for AI-enabled scientific results

The program has four tracks, each with distinct expectations and technical priorities:

1. UCSS (Usable and Collaborative Security for Science)

This track rewards work that makes security practical in science teams. The program language repeatedly notes collaboration barriers in modern science: different institutions, varied data governance, mixed software ecosystems, and varying levels of security expertise across user communities. A winning UCSS proposal needs to show that a security approach is usable for researchers and can be adopted in real workflows.

Typical proposal signals for strength in UCSS include:

• clear workflow-level security integration strategy,
• collaboration model across disciplines,
• concrete path for adoption by existing scientific CI communities,
• measurable outcomes (fewer security events, fewer workflow failures, improved uptake by domain scientists).

2. RSSD (Reference Scientific Security Datasets)

RSSD is dataset-centered. NSF asks for realistic metadata and workload traces from scientific computing environments so security researchers can evaluate and improve defenses on representative, high-value systems. The expectation is to collect, label, curate, and share datasets in a reusable way.

From the solicitation details, strong RSSD proposals should include:

• defensible collection methodology,
• clear explanation of utility for specific scientific communities,
• FAIR-aligned curation and sharing plan,
• ethical and privacy controls (especially where user or project-sensitive metadata may exist).

3. TCR (Transition to Cyberinfrastructure Resilience)

TCR is transition-oriented and emphasizes taking validated security work into operation within scientific CI environments. This is where test, evaluation, and deployment quality becomes central.

A competitive TCR narrative should explain:

• what innovation is being transitioned,
• where deployment is happening,
• how performance and security trade-offs are addressed,
• how reproducibility is improved in operational environments,
• what metrics define successful transition.

4. IPAAI (Integrity, Provenance, and Authenticity for AI-Ready Data)

This area addresses one of the fastest-growing risk vectors in scientific AI: compromised or untraceable datasets. Proposals in this track focus on confidence in data used for AI-driven discovery, including provenance, integrity, and authenticity.

Strong IPAAI proposals typically define:

• the data origin and integrity risk model,
• logging and traceability approach,
• impact of compromised data on model outputs,
• how outcomes remain auditable over time.

Eligibility and fit: who should apply and who should not

CICI has constrained institutional eligibility, so this is not suitable for every organization. You need to map your applicant type before investing in writing.

Eligible proposers

The solicitation says proposals may be submitted by:

• Institutions of Higher Education (IHEs), including two- and four-year institutions (community colleges included), accredited in the U.S., acting on behalf of their faculty members,
• U.S.-located non-profit, non-academic organizations directly tied to educational/research activities (examples include observatories, research labs, professional societies).

This means most for-profit firms, general private entities, and unrelated non-profits will not fit directly.

PI and personnel structure

NSF explicitly says there are no blanket PI restrictions for CICI, but it does enforce submission limits at person level:

• one person can be PI, co-PI, or senior/key personnel on up to two proposals.

This appears strict and should be treated as a hard compliance point because exceeding it can return proposals without review.

Collaboration structure

A notable compliance point appears in the eligibility section: proposals from different organizations cannot request separate awards in a single submission if done as collaborative multiple-award structure. NSF expects a single proposal with one requested award and sub-awards where needed via a lead organization.

This matters for multi-institution project teams. If your consortium model assumes split awards, you need to restate it into lead/prime plus sub-award architecture.

Geographic and institutional practicality

Because this opportunity is targeted to US institutions and institutions operating US infrastructure, non-US applicants should not expect this to be an open-track route. Also, international branch campuses may be possible only with specific justification and explicit benefit-to-project rationale.

Funding mechanics, budget framing, and financial planning

CICI provides a total program envelope but does not guarantee full funding for every proposal category. The text lists expected award totals and per-award caps by track:

• UCSS: up to $600,000 over up to 3 years,
• RSSD: up to $600,000 over up to 3 years,
• TCR: up to $1,200,000 over up to 3 years,
• IPAAI: up to $900,000 over up to 3 years.

Estimated awards are 12–20 across tracks, so not every proposal that is technically good will get funded. Internal planning should account for this competition ratio.

Budget logic that tends to trip teams

A recurring problem is using this as a pure research-seeding grant with high-cost speculative spending. The program text is practical and operationally oriented. Budget reviewers will look for work aligned with transition, validation, and deployment, and these often require:

• realistic staff and partner support for deployment,
• software and infrastructure costs where needed,
• travel for PI review/coordination where expected,
• reproducibility and evaluation infrastructure for evidence generation.

Voluntary committed cost sharing is explicitly prohibited. Teams should not include it unless you are sure it is not committed cost share. If you plan matching effort internally, it must be treated carefully and never represented as a required condition for award competitiveness.

Interpreting “annual recurring” correctly

NSF shows past cycle dates in the solicitation (including April 2025 and Jan 2026) and then indicates a recurring January Wednesday anchor. This is a critical planning detail: teams that miss one cycle can often aim for the next if they remain compliant with that cycle’s timeline and review structure. For your internal workflow, treat this as a rolling-cycle solicitation that still requires fixed preparation windows.

2026/2027 cycle planning and application timeline

For teams tracking this in practice, the best way to stay competitive is to plan backwards from deadlines and review events.

Current date context and cycle choice

As of this check, this solicitation remains listed as current. In a 2026/2027 context, applicants should decide whether they are targeting the next January cycle or using this as a multi-cycle proposal in progress.

A practical planning split:

• Cycle-incremental plan: prepare now, submit this year’s next cycle, and carry learnings into the following cycle if not funded,
• Long-window plan: build proposal architecture one cycle ahead by preparing reusable core sections, then adjust only cycle-specific metadata and partner commitments.

Recommended preparation timeline

• T-20 weeks: define track, assemble team, secure institutional approvals and COI/POC responsibilities,
• T-16 weeks: finalize technical approach and partner letters for collaboration evidence,
• T-12 weeks: draft full narrative sections by sections against eligibility and review criteria,
• T-8 weeks: complete PIs, budget, letters of collaboration, and FAIR data sharing plan (especially critical for RSSD/IPAAI),
• T-4 weeks: full compliance pass against NSF proposal instructions and CICI-specific title/format/structure,
• T-1 week: portal rehearsal and deadline contingency checks,
• T-0: final submission, technical proofing, and portal submission receipts.

Application process: what to submit and in what order

NSF allows proposal submission through Research.gov or Grants.gov. The solicitation requires that all proposals use the relevant PAPPG and Grants.gov guidance depending on your portal.

Step 1: Track-specific architecture

Pick one primary track per proposal; do not submit one narrative that tries to satisfy all four areas. The proposal should make tradeoffs explicit.

• UCSS: emphasize human factors and science workflow compatibility.
• RSSD: emphasize dataset lifecycle, curation quality, ethics, and dissemination.
• TCR: emphasize transition and deployment evidence.
• IPAAI: emphasize provenance architecture and integrity controls.

Step 2: Build institution-ready evidence

For each track, your proposal should tie claims to evidence:

• existing infrastructure ownership,
• team capability in cybersecurity and scientific systems,
• partnerships and community impact,
• dissemination or transition paths beyond one institution.

Step 3: Proposal format and title discipline

The solicitation requires title structure to begin with CICI:<track acronym>:title. This may seem minor, but title formatting is part of compliance hygiene. Keep track acronyms consistent across internal document references.

Step 4: Commonly missing but critical attachments

Use PAPPG checklist and the solicitation guidance together. Ensure project personnel lists, partner orgs, and collaboration evidence are complete and structured. The page is explicit that letters of collaboration can be required evidence, not optional narrative ornaments.

Review mindset and competitive positioning

The solicitation references standard NSF National Science Board criteria. In practical terms, most teams are judged on both technical quality and operational execution quality.

What review panels generally reward

• clear alignment to one track’s problem statement,
• a concrete transition and adoption path,
• measurable impact claims tied to scientific communities,
• robust ethical handling of data,
• reproducibility planning and open software practices where appropriate.

What reduces competitiveness

• treating the proposal as generic cybersecurity rather than cyberinfrastructure-specific,
• weak links between proposal outputs and active scientific workflows,
• no concrete adoption plan for software, datasets, or transition,
• unclear PI/person limits risk or collaborative governance design.

Common mistakes to avoid (with quick fixes)

1. Mistake: missing the recurring deadline context

   Teams assume there is a single immutable deadline and submit late to a closed review point. Keep a rolling calendar and verify whether your target path is the current or next annual cycle.

2. Mistake: ignoring PI/person caps

   Include an internal PI proposal cap check at draft stage. If a PI appears on more than two proposals in this solicitation, later submissions can be returned without review.

3. Mistake: overbroad scope across all four tracks

   CICI tracks are distinct. Pick one and make that the full spine of the project design.

4. Mistake: omitting FAIR and public-sharing strategy in RSSD and IPAAI

   For curated datasets and AI provenance tracks, data lifecycle and sharing compliance are central. Include repository strategy, metadata treatment, and long-term maintainability.

5. Mistake: no transition metrics for TCR-style work

   The solicitation repeatedly highlights transition into operation. If the proposal has no concrete maturation and deployment metrics, review quality drops.

6. Mistake: weak compliance with collaboration structure

   If multiple organizations participate, use one lead and single award language appropriately and avoid structures that imply separate award requests for each organization.

Frequently asked questions

Is this a one-time competition or ongoing?

It is positioned as recurring with annual third-Wednesday-of-January full proposal deadlines after the listed dates. That means teams should monitor current cycle details, not assume a single-year one-off opportunity.

Can the same institution submit multiple proposals?

The eligibility text says there are no limits on number of proposals per organization, but there is still a strict individual PI/co-PI/key personnel limit.

Can non-university organizations apply?

Yes, but only specific non-profit, non-academic U.S. organizations tied to educational or research activities, as listed by NSF. This is not an open for-profit mechanism.

Is cost sharing required?

No. Voluntary committed cost sharing is explicitly prohibited.

Is this suitable for pure defensive cybersecurity theory?

The solicitation is targeted at scientific infrastructure and scientific workflows. Fundamental cybersecurity or broad non-cyberinfrastructure research is not intended for this channel.

What makes a proposal reviewer-competitive?

Concreteness: choose one track, show measurable scientific impact, show transition architecture, and show that security is designed for real-world users and real-world constraints.

Preparation checklist for immediate action

Before submission, complete this one-page internal checklist:

• Track selection: one primary track chosen and named in title.
• Institution type: confirmed eligible organization and lead/partner governance.
• Program fit: proposal addresses scientific CI, not generic security.
• Evidence links: collaborators, communities, datasets, or testbeds cited.
• Data policy: FAIR-aligned handling where dataset sharing is included.
• Submission route: Research.gov or Grants.gov selected and instructions followed.
• Compliance: no prohibited cost sharing, PI participation cap checked.
• Review readiness: success metrics and transition plan quantified and measurable.

Use this as a hard gate before submission.

Official links and source references

• Program solicitation: https://www.nsf.gov/funding/opportunities/cici-cybersecurity-innovation-cyberinfrastructure/nsf25-531/solicitation
• Base program page (where available through NSF page links): View the program page
• PAPPG and Grants.gov guidance: links provided on the NSF solicitation page
• Research.gov and Grants.gov application technical support: links listed directly in the solicitation

If your team is in the 2026/2027 planning window, this is a good opportunity to bookmark as recurring and design internal processes that can be reused for each cycle rather than rewriting from scratch each time.