NSF 26-509: Integrated Data Systems & Services (IDSS) Cyberinfrastructure Grant
The 2026 NSF IDSS solicitation supports national-scale integrated data systems and services that advance open, data-intensive, and AI-driven research across many scientific and engineering communities.
Deadline not clearly published; check the official source before planning around this.
NSF 26-509: Integrated Data Systems & Services (IDSS) Cyberinfrastructure Grant
The Integrated Data Systems & Services (IDSS) solicitation under NSF 26-509 is one of the clearest examples of a large, active U.S. federal funding call for cyberinfrastructure in 2026–2027. It is not a small grant for a single lab project; it is explicitly designed for national-scale systems and services that support broad scientific use. The opportunity was posted on April 15, 2026 and is identified as active on the NSF opportunities page, with full proposal deadlines in July 2026 and July 2027 by category. The page also lists expected award forms and funding scales that can reach tens of millions of dollars for Category I projects.
The call is aimed at teams that can build or scale durable data infrastructure with practical impact across research and education, not narrowly scoped experiments or single-lab software tools. If your concept depends on interoperable data systems, long-term operations, or a design that can serve multiple research domains, this is one of the few NSF opportunities that matches that profile directly.
Key details at a glance
| Item | Details |
|---|---|
| Opportunity | NSF 26-509: Integrated Data Systems & Services (IDSS) |
| Host | U.S. National Science Foundation (Office of Advanced Cyberinfrastructure, CISE) |
| Posted | April 15, 2026 |
| Main deadline | July 28, 2026 |
| Category II deadline | July 27, 2027 |
| Category I/III follow-up | Recurring on the fourth Tuesday in July, annually thereafter |
| Proposal windows | Full proposals; no letters of intent required |
| Award form | Standard Grant (Category III) and Cooperative Agreement (Category I/II) |
| Estimated awards | 3 to 9, with 1 to 2 each for Category I and II; 1 to 5 for Category III |
| Funding range | $500,000 to $60,000,000 across categories |
| Eligible proposers | U.S. IHEs; U.S. non-profit non-academic research organizations; qualified U.S. federal agencies/FFRDCs |
| Key limits | One lead proposal per organization for Category I and II per solicitation deadline; one PI/co-PI role across Category I and II |
| Eligibility note | Collaborative proposals are allowed but must be submitted as a single proposal/award with subawards for partner entities |
| Cost sharing | Voluntary committed cost sharing is prohibited |
Why this opportunity is relevant now
The NSF explicitly frames IDSS as a program for operations-level, national-scale data systems and services that enable open, data-intensive, and AI-driven science and engineering. In plain terms, this means NSF is not asking for one-off prototypes that end with a publication; it is asking for infrastructure that can run and scale over years.
That distinction matters. NSF created this line of investment because many institutions can build impressive tools, but far fewer can operate resilient infrastructure across communities with predictable access, performance, and governance. If your organization already has a proven pilot or regional platform and can document reproducible demand across user communities, IDSS is often a better match than more general NSF research awards.
The timeline is also attractive for teams planning for an ongoing 2026–2027 cycle. The first full deadline sits in late July 2026, and the listing indicates recurring cycles and a Category II window in 2027. For institutions that were not ready by 2026, this still leaves room to reframe and resubmit in the next cycle without waiting years for a similar solicitation.
What the solicitation is actually funding
The program is built on three categories with materially different scope, scale, and likely workload:
Category I: Development, deployment, and operation at national scale
Category I supports novel national-scale data systems and services, with budgets between $10 million and $30 million for up to five years, and explicitly described as potentially renewable. These proposals are expected to either create new capabilities or combine existing ones into scalable systems that support broad user communities.
The expectation is national impact, not incremental local upgrade. Proposals should describe:
- Clear national-level use cases for the system,
- how performance and operations are designed for broad, multi-disciplinary users,
- what the project contributes to interoperability with existing infrastructure,
- evidence that the proposed system would not just be useful, but necessary.
Category II: Transitioning operational regional systems to national scale
Category II targets projects that already have proven smaller-scale or pilot systems and are ready to expand toward national operations. The solicitation caps these at up to $9 million for up to three years, with potential renewals possible.
This is a strong fit for organizations running proven observatory-like services, domain-specific data operations, or distributed infrastructure components that have users but need reliability, operational maturity, and broader federation.
A key nuance in Category II is that NSF expects existing strong use cases and measurable user demand before scaling. In review, teams that can show real throughput, existing adoption, and clear pathways for scaling generally fare better than those proposing only concept-level architecture.
Category III: Planning grants
Category III is explicitly for planning future development or transition proposals and has a budget cap of $500,000 for up to two years. These grants are not for technical implementation. They are for planning: evidence mapping, engagement, requirement development, and concrete readiness activities.
NSF says Category III proposals cannot include technical development or operations activities, so teams should avoid budgeting or planning for software engineering outputs as full deliverables at this stage. This category is useful for institutions that need an NSF-backed pre-award phase to make a future Category I or II proposal coherent.
One practical implication of the three-track structure
Many teams incorrectly try to blend all stages into one proposal and lose clarity. Because the funding structures are different, your first decision should be category-first. For new teams without an existing national-scale operation, Category III can de-risk the process and convert a strategic concept into an implementation-ready plan. For mature teams already running reliable systems, Category II is often a clearer route to growth.
Eligibility and compliance: the constraints that eliminate weak entries
The solicitation is precise about who can submit and how often:
- Proposers must be U.S. institutions of higher education (2- or 4-year, including community colleges), U.S. non-profit non-academic research organizations, or certain U.S. federal agencies/FFRDCs subject to PAPPG limitations.
- There are no explicit PI-level status barriers like citizenship filters in the short eligibility section we have, but all proposals still must comply with NSF rules in the full solicitation.
- Each organization may submit only one lead proposal for Category I and one for Category II per deadline.
- An individual may not appear as PI/co-PI/senior personnel on more than one lead proposal across Categories I and II for the same deadline.
This means teams should create a clear internal governance process before submission:
- Decide which PI will front which category.
- Decide whether a second organization proposal can be a subaward instead of a separate lead.
- Freeze roles to prevent a PI from overlapping categories.
- Verify whether your institution has internal policies for single-lead limits on federal grant submissions.
The page also states that collaborative efforts should be submitted as single proposals with one award, with partner involvement routed through subawards. That requirement can be a point of confusion for teams used to multi-institution equal-lead models. Prepare your consortium structure accordingly.
Another important compliance item: the page lists no voluntary committed cost sharing. If your internal finance team assumes matching funds are expected, that assumption is wrong and can weaken application alignment.
Review expectations and what distinguishes a strong IDSS concept
The NSF evaluation is based on the National Science Board criteria plus additional solicitation-specific criteria. The program text repeatedly emphasizes transdisciplinary impact and broad applicability.
In practical review terms, strong proposals usually satisfy all of the following:
- They avoid discipline-only outcomes and articulate broader benefit across multiple domains.
- They show explicit data lifecycle understanding (acquisition, transfer, analysis, sharing, curation, and reuse where relevant).
- They show how their design contributes to an integrated and federated infrastructure, not a standalone silo.
- They include an operations plan with milestones and performance targets that can be measured post-award.
- They provide a user onboarding and support design that matches national-scale expectations.
- They plan for open science principles through reliable interoperability with instrumentation, repositories, and compute layers.
The line about open software is especially strong: any software developed under IDSS must be made publicly available under an open-source license. Proposals with uncertain licensing plans can be flagged early.
Reviewers also tend to penalize projects that are “continuations with minimal changes.” This is a frequent failure mode: teams reuse existing infrastructure branding with small modifications and frame it as a national buildout. The call requires substantial change and new national-level value, especially for Category I. Category II can use existing roots, but still needs clear evidence of scalability and broad expansion.
Application process and submission workflow
The solicitation states full proposals only are required; there is no required letter of intent or preliminary submission stage listed for this cycle. A practical workflow looks like this:
- Select a category (I, II, or III) based on maturity and deliverables.
- Confirm internal eligibility (lead proposer, PI role, and organization limit constraints).
- Draft a project narrative that maps tightly to category-specific expectations.
- Prepare the title to include the exact category prefix: “Category I:”, “Category II:”, or “Category III:” as required by the Cover Sheet instructions.
- Build a proposal structure aligned with required sections:
- Vision, goals, and required use cases,
- Project definition and architecture,
- Operations plan and maintenance,
- Performance objectives,
- Budget and project management.
- Decide submission channel:
- Research.gov route for applications prepared under NSF PAPPG,
- Grants.gov route under NSF Grants.gov guidance when used.
- Submit before the local-time deadline at the listed date and preserve backup for system issues.
The page also warns that collaborative submissions should use a single proposal with clear subaward architecture. That matters operationally because some teams treat this as a standard joint submission with parallel lead models and lose eligibility.
For category choice, think in terms of reviewer burden:
- Category I demands clear national-scale architecture and five-year operating readiness arguments.
- Category II needs explicit evidence that existing systems already work and can scale to national operations.
- Category III should present a disciplined readiness plan and not promise implementation.
If you miss that distinction, your proposal reads as either too speculative (if you propose execution in Category III) or too conservative (if you submit Category II with no scale evidence).
Preparation strategy for a stronger application
To increase chances of competitiveness, teams should treat IDSS applications as infrastructure policy and operations documents, not just technical specifications.
Start with evidence of broad impact
The opportunity is not meant for projects serving one lab, one project, or one narrow customer class. Build a concise argument for cross-disciplinary uptake. If you say “this will help X,” support with quantified adoption signals and examples of communities that will use the infrastructure.
Include:
- usage data from existing pilots,
- expected growth curves,
- classes of users across domains,
- integration points with other national infrastructure.
Show data lifecycle clarity
The solicitation values end-to-end design. Proposals should identify which lifecycle stages they target and why those stages are sufficient for user outcomes. Even if the project touches only selected stages, the proposal should explicitly explain the boundary and how users hand off work across the pipeline.
Design for operations early
For Categories I and II, operations are central. Reviewers will expect a first-year operations readiness path. Define:
- performance targets,
- staffing model for sustained operations,
- user support structure,
- training and onboarding strategy,
- upgrade and refresh planning.
Do not reduce this section to infrastructure architecture alone. Many proposals fail at this stage because they under-specify support and monitoring mechanisms.
Build measurable criteria
Include measurable goals and targets: latency, throughput, access availability, user growth, integration success, and service reliability metrics. NSF expects project success to be judged with concrete evidence.
Align with open, shared standards
Because the page emphasizes openness and broad reuse, show clearly how your systems interface with existing computing resources, repositories, and facilities without duplicating everything. Position your contribution as a connective layer and a scalable enhancement.
Prepare the institutional package and roles
Since limits are strict on number of submissions and PI overlap, set a pre-submission institutional rulebook:
- Which unit submits Category I vs II,
- who serves as PI and co-PIs,
- what each partner becomes through subaward,
- legal and budget responsibilities for open-source licensing.
Budget realism
Award sizes are large and diverse across categories. Build a realistic staffing and operations plan with explicit non-renewable planning constraints for Category III and potential renewal logic for Categories I and II. Even though the solicitation allows renewals, they depend on performance and review outcomes. Avoid assuming continuation.
Common mistakes that can sink a proposal
- Submitting category-inappropriate scope
Applications that mix long-term implementation and planning activities in Category III often fail because this category cannot include technical implementation.
- Trying for international funding through ineligible partner structures
The solicitation indicates the NSF channel does not permit awards to include funding for international partners. Projects may still engage global users in some form, but funding structure must respect NSF rules.
- Ignoring internal limit rules
The one-lead-per-category and one-PI-across-category limits are strict. Noncompliance can trigger returns without review.
- Using old cost-sharing assumptions
The page explicitly prohibits voluntary committed cost sharing. Writing a budget assuming matching funds as a mandatory condition can create a weak message and possible compliance issues.
- Underestimating operations planning
Some teams focus on architecture and omit detailed operational rollout and support. IDSS explicitly funds operational systems; operations quality is part of scientific value in this solicitation.
- Narrowing to one discipline
The solicitation is explicit that primarily discipline-bound projects are not supported. If your use case is too narrow, it may be rejected early as out of scope.
- Treating this as a software product pitch
The page’s requirement for national-scale service readiness, interoperability, and open-source conditions favors infrastructure projects with durable mission and governance, not just a product launch.
Official timeline interpretation and planning recommendation
The publication date and active status in 2026 signal a current cycle. The July 28, 2026 full-proposal deadline appears the immediate priority date for Category I/III, and a 2027 Category II date indicates continuation into the next cycle.
Given this cadence, a practical internal timeline for teams is:
- Now to mid-June 2026: finalize category and partner structure, gather data for scale evidence.
- Late June 2026: complete first full draft with evidence of broad user demand.
- Early July 2026: internal compliance review for title format, PI limits, and submission pathway.
- Late July 2026: submit and validate before deadline.
- Post-submission: use reviewer feedback and outcomes to rework for 2027 windows if needed.
Organizations should not wait until the last day for large proposals that involve multiple stakeholders and institutions. NSF portals are strict on submission timing and technical failures can become outcome-critical.
Frequently asked questions (based on the published solicitation)
Is this open only for 2026?
No. The solicitation includes recurring deadlines and a 2027 Category II date, so it is usable for planning a near-term 2026 submission or a 2027 follow-up.
Who can lead the proposal?
An eligible U.S. IHE or U.S. non-profit non-academic research organization can lead, subject to NSF rules. Federal agencies and FFRDCs have additional chapter-specific constraints.
Can we submit more than one full proposal per institution?
Not for Categories I and II per deadline as lead institution. One each across Category I and II is allowed. Category III has separate treatment.
Do we need a letter of intent?
No. Full proposals are the entry point listed for this solicitation.
Do proposals need cost matching?
No. Voluntary committed cost sharing is explicitly prohibited.
Can we include software code development in Category III?
No. Category III is planning; technical development and operational activity are not intended for this stage.
Are collaborative proposals allowed?
Yes, but they are constrained by NSF’s single-proposal structure and subaward model.
Next steps checklist
- Confirm category (I, II, III) against your current project maturity.
- Validate proposer and PI/compliance limits for your institution.
- Build a cross-disciplinary impact narrative from the first page.
- Draft a realistic operations and user service plan.
- Include performance metrics and open access/interop design.
- Confirm title prefix and submission channel.
- Submit before the July deadline and keep full proposal artifacts organized for 2027 if needed.
Official links
- Official NSF IDSS opportunity page (resolved): https://www.nsf.gov/funding/opportunities/idss-integrated-data-systems-services/nsf26-509/solicitation
- NSF Funding page: https://www.nsf.gov/funding
- Grants submission systems: https://www.research.gov and https://www.grants.gov
- NSF Proposal guidance: see the NSF page references to PAPPG in the solicitation.