Estimated reading time: 5 minutes · Last updated:
The Software Engineering Institute has released a framework that identifies seven priority areas and 37 specific research opportunities intended to steer cybersecurity research toward national-security missions. Bill Scherlis, the framework’s editor, and Greg Touhill of SEI’s CERT Division led more than 25 SEI technical experts in identifying enduring problems where research can produce operational gains. Their aim is to push researchers and developers to build capabilities that work for mission operators, not only lab demonstrations. The primary call is clear: align research to mission risk and to long-lived systems.
There is greater urgency than ever before to take considered action to improve the nation’s cybersecurity posture — and in a way that accelerates the delivery of capability to the mission.
Bill Scherlis, framework editor and special adviser to the director of the SEI
Key takeaways
- The SEI framework isolates seven enduring topic areas that the institute judges to offer the greatest operational returns for national-security cyber work.
- It lists 37 research opportunities across those seven areas to guide near- and long-term R&D choices.
- More than 25 SEI technical experts contributed to the framework, with Bill Scherlis serving as editor and Greg Touhill providing input.
- The framework urges structuring research around threats, mission consequences and system vulnerabilities rather than technical novelty alone.
Table of contents
- Key takeaways
- What the SEI framework sets out and why it matters
- How the framework treats AI, testing and system composition
- A mission-focused structure: threats, consequences and vulnerabilities
- How leaders, funders and developers are asked to respond
- How the case for and against the framework breaks down
- What to be careful about
- Frequently asked questions
What the SEI framework sets out and why it matters
The SEI framework groups research needs into a compact set of priorities intended to be useful to researchers, operators and product teams. It highlights seven topic areas where investments are likely to produce durable improvements in cyber operations across national-security missions. The document also enumerates 37 concrete research opportunities that are framed as either near-term actions or longer-term lines of work.
This is a practical shift: SEI’s team judged that chasing the latest tool or technique is less effective than focusing on problems that persist as technologies and adversaries change. The project was led by Bill Scherlis, who edited the framework, and Greg Touhill, director of SEI’s CERT Division, and it draws on the input of more than 25 SEI technical experts. That mix is meant to link academic research to operational needs.
How the framework treats AI, testing and system composition
One of the seven topics the framework flags is work on AI and the systems that use it. SEI identifies research needs around deploying AI capabilities even when component models retain weaknesses — in short, how to put imperfect AI into larger, safer systems and how to test those assemblies effectively.
The framework calls for better methods to probe AI systems, to identify vulnerabilities and to judge whether deployed safeguards actually reduce operational risk. That emphasis shifts some research attention from producing larger models toward engineering practices that make AI components dependable in mission settings.
A mission-focused structure: threats, consequences and vulnerabilities
Rather than proposing a taxonomy of technologies, SEI recommends that research agendas be organised around three elements of cyber risk: the nature of potential adversary actions, the mission-level consequences of a successful intrusion, and the vulnerabilities inside the systems that missions depend on. Framing research this way forces evaluators to connect a technical fix to how it actually reduces harm to an operation.
That approach underpins several of the 37 opportunities, and it is why the framework stresses testing and measurement: to show that a research outcome meaningfully lowers mission risk. SEI’s team argues this is the route to faster delivery of operational capability, because operators and acquisition teams can prioritise the work that most directly reduces the risks they face.
How leaders, funders and developers are asked to respond
SEI’s authors address research organisations, government programmes and product developers. The framework is a call to align funding, testing regimes and development roadmaps so that R&D produces capabilities usable by mission operators rather than only proving a concept in isolation. Greg Touhill and Bill Scherlis explicitly ask leaders across research, operations and product development to use the framework to set vision-driven agendas.
If research funders incorporate the framework’s priorities into solicitations and if engineering teams adopt its testing and integration recommendations, the document’s authors say the result should be faster, more reliable delivery of capability to missions. The framework therefore functions as both a diagnostic and a set of practical priorities for those choosing what to study or build next.
How the case for and against the framework breaks down
The case for
- Targets limited resources: by naming seven areas and 37 opportunities, the framework gives funders concrete choices to prioritise work that reduces mission risk.
- Makes research evaluable: its emphasis on testing and mission-relevant metrics could shorten the path from prototype to operational use if adopted by acquisition and procurement programmes.
The case against
- Adoption is voluntary: without explicit buy-in from major funders or defence programmes, the framework risks remaining descriptive rather than directive.
- Operational constraints may limit applicability: some recommendations depend on access to live mission environments for testing, which can be costly or politically difficult to arrange.
What to be careful about
- The framework will not change practice unless procurement and funding bodies incorporate its priorities into calls and roadmaps, which the document itself cannot compel.
- A focus on mission-relevant testing requires access to realistic operational data and environments; lacking those, research results may remain unproven against real threats.
- If research groups prioritise short-term demonstrable outcomes to meet funding cycles, longer-term or systems-level work the framework recommends could be under-resourced.
The bottom line
The SEI framework reframes cybersecurity research toward operational effect: seven topic areas and 37 listed opportunities give funders and developers a focused menu of work that, if adopted, could shorten the route from research to fielded capability. Its practical thrust is testing, integration and mission-aligned metrics rather than novelty for its own sake. The next step is institutional: federal programmes, acquisition offices and major funders must incorporate these priorities into calls and roadmaps if the framework is to move from guidance into practice.
What to watch
- Watch for research funding solicitations that cite the SEI framework and its seven topic areas; no date has been set.
- Watch for government research or procurement roadmaps to reference the framework’s 37 research opportunities; no date has been set.
- Watch for academic and industry groups to align project calls to the framework’s priorities; no date has been set.
Frequently asked questions
Who produced the framework and how many experts contributed?
Carnegie Mellon University’s Software Engineering Institute produced the framework; more than 25 SEI technical experts contributed, with Bill Scherlis serving as editor and Greg Touhill of SEI’s CERT Division involved.
How many research priorities does the framework identify?
It lists seven broad topic areas and 37 specific research opportunities, with the opportunities framed as near-term actions or longer-term lines of work.
What practical change does the framework ask of funders and developers?
The framework asks funders and engineering teams to align projects and testing to mission risk — that is, to prioritise work that demonstrably reduces threats, mission consequences or system vulnerabilities rather than only advancing technical novelty.
Related reading
