Who owns the code between your systems?
Your agency’s major systems, from ERP and finance to public safety, land management and utility billing, went through a security review before you bought them. They come with audit reports, support contracts and patch schedules. But what about the code that connects them to each other, and to payment processors, GIS, document management and resident portals?
At many cities, counties and state agencies, that code is a self-hosted integration: custom scripts or middleware a vendor wrote, installed on an agency server and handed over. It works, until someone asks who owns it.
Attackers are already asking. In the public sector, 40% of breaches in the 2026 Data Breach Investigations Report began with an exploited vulnerability, and 36% involved a third party. Critical vulnerabilities took a median of 43 days to fully fix.[1] In 2023, a single flaw in widely used file-transfer software exposed driver’s license data for every license holder in Louisiana and about 3.5 million Oregonians.[2]
State security leaders see it coming: 78% of state CISOs name third-party breaches as their top expected threat, yet only 22% feel highly confident they can protect public data.[3]
Self-hosted integrations carry this risk with less visibility:
And the capacity to manage it is thin: 68% of state, local, tribal and territorial organizations say they lack the budget to address major cybersecurity priorities.[7] Today’s custom code is tomorrow’s legacy system.
Not every self-hosted integration is unsafe. But CISA’s Secure by Design principles say the burden of security belongs with the software maker, not the customer.[8] The question is whether your vendor’s integration approach puts it there.
Start by asking. Download the Integration Security Checklist: the questions every agency should put to any vendor proposing a self-hosted integration.