Scaling Threat Modeling for Government Agencies

For state and local agencies, threat modeling for government agencies is no longer a specialist exercise reserved for a handful of flagship systems. Agencies now run benefits portals, permitting and licensing platforms, tax and revenue systems, 911 and public safety applications, court records, and payment services, most of them built or hosted by vendors and connected to each other through shared identity and data services.

That footprint delivers public services faster. It also concentrates risk in places that are hard to see.

The question in 2026 is not whether agencies should threat model. Most CISOs already accept that design-level review catches problems testing cannot. The question is how to do it across dozens or hundreds of applications with a small security team, a procurement cycle measured in years, and systems the agency does not fully control.

Manual threat modeling has hit its ceiling in most agencies. Reviews happen when a project is large enough to get attention. Diagrams live in vendor proposals and go stale after go-live. Findings cannot be compared across departments. The applications that fall through are often the small ones, until one of them becomes the entry point.

---

Why Manual Threat Modeling Breaks Down in Government

Government environments have the same scaling problem as any large enterprise, plus a few that are specific to the public sector:

• Vendor-built and vendor-hosted systems. Many applications are delivered under contract. The agency owns the risk but not the code, the architecture decisions, or the change schedule.
• Long-lived legacy platforms. Mainframe-era benefits, tax, and records systems sit behind modern web front ends. The threat model has to cover the seam between them, which is where assumptions fail.
• Shared services across agencies. A statewide identity provider, payment gateway, or data warehouse means one design flaw can reach many departments.
• Overlapping data obligations. Criminal justice information, federal tax information, health data, and student records often sit in the same environment, each with its own policy regime.
• Procurement timing. Security requirements written after a contract is signed are expensive to add. Threat modeling that starts at go-live is already too late to shape the design.
• Small teams, wide scope. A handful of security staff may be responsible for every department, county partner, and vendor.

When a threat is missed in this setting, the impact is not limited to data exposure. It can mean benefits that stop paying, emergency services that degrade, court operations that halt, or a loss of public trust that outlasts the incident.

---

The 2026 Model: Risk-Based Threat Modeling Across the Portfolio

Scaling threat modeling does not mean asking every program office to become a security team. It means building a system where mission context, architecture, adversary behavior, and compliance obligations feed the same decisions.

A mature program helps an agency answer five questions:

1. Which public services and data matter most if they fail?
2. Who would target them, and why? (ransomware crews, fraud rings, hacktivists, nation-state actors)
3. How could the system, or the vendor behind it, be abused?
4. Which controls reduce the most meaningful risk?
5. How do we show progress to leadership, auditors, and the legislature?

The goal is not more documentation. It is better security decisions earlier, ideally before a contract is signed. For a methodology that ties these questions to business and mission impact, see PASTA threat modeling.

---

Step 1: Tier Applications by Mission Impact

Start by classifying applications by what happens if they fail or are compromised, not by department or budget size.

A public-facing unemployment portal, a computer-aided dispatch system, and an internal facilities scheduling tool do not need the same depth of review. Treating them the same wastes scarce expertise.

A practical tiering model considers:

• Life-safety and public-safety impact
• Payment or benefit disbursement
• Regulated data (criminal justice, federal tax, health, student, or voter information)
• Internet exposure and citizen-facing access
• Identity and authorization complexity, including caseworker and delegated-user roles
• Connections to shared state services or other agencies
• Vendor hosting and vendor administrative access
• Fraud potential
• Recovery expectations and statutory deadlines

High-tier systems get deep, recurring analysis and validation. Lower tiers get a lighter baseline. The deepest expertise goes where failure would hurt the public most.

---

Step 2: Move Threat Modeling Into Procurement and Design

In government, the most important delivery moment is often the procurement, not the sprint.

Build threat modeling into:

• Requirements and RFP development for new systems
• Vendor solution review before contract award
• Architecture design for modernization and cloud migration
• Integration with shared services (identity, payments, data exchange)
• Major change requests under existing contracts
• Pre-launch review for citizen-facing releases
• Post-incident review when an event exposes a design weakness

The agencies that make this work usually split responsibility. The security office sets the standard and reviews high-tier systems. Vendors supply data flows, trust boundaries, and abuse cases as a contract deliverable. Leadership sees risk trends across the portfolio, not one report per project.

Writing threat model deliverables into contracts is the single change with the most leverage. It moves the work to the party that knows the architecture and gives the agency a document it can hold the vendor to.

---

Step 3: Standardize the Method Without Turning It Into Paperwork

A consistent method lets the agency compare risk across departments regardless of who ran the review or which vendor built the system.

Standardize the core elements:

• System and mission overview
• Data classification and the policy regimes that apply
• Trust boundaries, including agency, vendor, and shared-service boundaries
• User roles: public users, caseworkers, administrators, vendor support staff
• Integrations with other agencies and federal partners
• Authentication flows, including the statewide identity provider
• Threat scenarios, existing controls, and gaps
• Risk ratings, remediation owners, and validation evidence

Keep it flexible. A dispatch system, a licensing portal, and a data-sharing API will have different threat patterns. The method should be consistent enough to compare and loose enough to reflect real architecture.

---

Step 4: Model Attack Paths, Including Fraud and Abuse

Generic threat lists are accurate and rarely useful. They do not show how an attacker gets from the internet to the outcome that matters.

Attack paths do. For example:

• Instead of “weak identity proofing,” map how a fraud ring could register synthetic identities at scale and redirect benefit payments.
• Instead of “third-party risk,” trace how a compromised vendor support account could reach a records database through a remote-access tool left in place after go-live.
• Instead of “API authorization,” show how a public records API could return another resident’s case details by changing an identifier in the request.

Fraud deserves equal weight with intrusion. Many of the most costly public-sector incidents involve legitimate functionality used at scale by people who are not who they claim to be. A threat model that only looks for exploits will miss them.

---

Step 5: Turn Threat Models Into Compliance Evidence

Agencies answer to several overlapping regimes: the FBI CJIS Security Policy for criminal justice information, IRS Publication 1075 for federal tax information, HIPAA for health data, state security standards, and cloud authorization programs such as FedRAMP and GovRAMP (formerly StateRAMP).

A cloud authorization covers the vendor’s platform. It does not cover how the agency configured it, integrated it, or exposed it to the public.

Threat modeling fills that gap by documenting:

• Why specific controls were chosen for this system
• Which risks were accepted, mitigated, or transferred, and by whom
• Where vendor and shared-service boundaries introduce risk
• How remediation was prioritized
• What testing confirmed the controls work

This gives auditors and oversight bodies a traceable line from threat to control to evidence, instead of a separate compliance exercise run after the fact.

---

Step 6: Automate the Repetitive Parts, Keep Judgment Central

Automation helps an agency cover more systems. It can support intake questionnaires, reusable threat libraries for common patterns (citizen portals, payment flows, data exchanges), control mapping, risk scoring, ticketing, and portfolio reporting.

It cannot judge mission impact. A tool can flag a weak session control. It cannot tell you that the affected system pays foster care providers, or that an outage during an emergency declaration has a different consequence than one on a quiet Tuesday. That judgment still needs people who understand both the architecture and the public service it supports.

This matters when agencies evaluate threat modeling providers or tools. Templates and dashboards are not the hard part. Connecting architecture, adversary behavior, and mission impact is.

---

Step 7: Measure Coverage and Outcomes, Not Workshops

Measure the program by what it changes:

• Percentage of high-tier systems with a current threat model
• Percentage of new contracts that include threat model deliverables
• Design issues found before award or before launch
• Time to remediate threat model findings, split by agency and vendor
• Recurring threat patterns across departments
• Coverage of shared services and inter-agency integrations
• Agreement between threat model findings and penetration test results

These translate into terms leadership and legislators understand: fewer surprises, better use of limited staff, and evidence that public funds are reducing risk.

---

Where This Gets Hard

Scaling threat modeling in government runs into limits worth stating plainly.

Existing contracts rarely require it. Until renewal, an agency may have to ask vendors for architecture detail they are not obligated to provide. Expect partial models for some systems for years.

Legacy systems cannot always be fixed. Some findings will end in compensating controls or documented risk acceptance, not remediation. The value is in making that acceptance explicit and owned, rather than unexamined.

Shared services blur ownership. When a finding sits in a statewide identity or payment service, the agency that found it may not be able to fix it. Programs need a clear escalation path across agency lines, or findings stall.

Staff turnover erodes context. Threat models written by one team are often unreadable to the next. Standard formats and plain-language risk statements matter more here than in most sectors.

---

What Good Looks Like

A mature program in a state or local agency is practical, not performative.

Vendors know threat modeling is part of the contract. Program offices know which of their systems are high-tier and why. The security team spends its time on attack paths in critical services rather than chasing diagrams. Auditors can trace a control back to the threat it addresses. Leadership can see which public services carry the most risk and where investment would reduce it.

For how this work is delivered as an ongoing service rather than a one-time engagement, see Threat Modeling as a Service for Healthcare in 2026, which covers both healthcare and government environments.

---

Final Takeaway

In 2026, threat modeling should not be limited to the few government systems large enough to get a dedicated review. It should be a repeatable, risk-based capability that starts in procurement and follows each system through its life.

Agencies that succeed will tie threat modeling to mission impact, write it into vendor contracts, and measure it by the risk it removes from the services the public depends on.

---

Sources

• StateRAMP announces rebrand to GovRAMP, GovRAMP, February 14, 2025
• Reference post: Scaling Threat Modeling for Banking Apps, VerSprite
• Threat Modeling as a Service for Healthcare in 2026, VerSprite

---

Frequently Asked Questions