Service Mapping for Government: Mapping Citizen-Service Risk

On February 23, 2026, Michigan claimants and employers logging into two different state systems, one for unemployment benefits and one for tax reporting, hit the same wall: locked out. The Michigan Department of Labor and Economic Opportunity notice was direct. MiLogin, the state’s shared sign-in portal, was intermittent. Both MiWAM and MiUI require MiLogin before either platform opens. Neither program’s own application had to fail for both citizen paths to stall. The shared authentication layer both depend on did.

In government IT, “mapping dependencies” often gets pictured as finding old systems nobody documented, or watching whether a portal is green on an availability board. Those jobs matter. They are not the job that decided how far that day spread. Service mapping for government and public sector has to answer a narrower question: which shared backends (identity, vendor platforms, integration middleware, cross-agency exchanges) feed which citizen-facing programs, and what is exposed when one of those backends fails.

Virima’s CMDB, discovery, and ViVID™ service mapping work on enterprise and shared IT infrastructure and the applications and processes they support. They do not monitor physical critical infrastructure such as power grids, water plants, or safety-instrumented control systems. Citizen-facing digital services fail when the IT layer underneath them stays opaque.

What Citizens See vs. What’s Actually Connected Underneath

Citizens experience government as separate products: benefits, taxes, licensing, courts. Agencies budget and staff the same way. A large share of what those products run on is shared. Sign-in portals sit in front of multiple applications. A single vendor platform may host unemployment and job-search workflows for many states. Middleware still moves case data between systems built decades apart. Cross-agency exchanges feed eligibility checks nobody sees on a homepage.

MiLogin makes the mismatch concrete. MiWAM and MiUI look like two products to claimants and employers. On February 23, 2026, both paths failed together because both require the same shared log-in step. Ownership of that step rarely sits fully inside either program’s application team. Inventory by department can still leave the shared layer under-described as a citizen-impact object.

Finding undocumented or contractor-run systems is a discovery problem. Knowing a shared identity system exists and still lacking a live picture of which citizen processes depend on it is a service-mapping problem. Those are sequential jobs, not synonyms.

What Cascades: When a Shared Backend Goes Down

Michigan’s notice tied the lockout to MiLogin, not to separate failures inside MiWAM and MiUI. Claimants managing benefits and employers filing tax and UI reports both needed that portal. The public message that day did not hand citizens a clean recovery clock. Shared-layer incidents often leave program teams waiting on a system they do not fully control.

The pattern scales past one state. In 2022, GovTech reported that Geographic Solutions took systems offline after an attempted malware attack. The vendor’s platforms underpinned unemployment and job-seeking sites across a large set of states and Washington, D.C. Louisiana residents waited as long as 72 hours in some reporting. Tennessee described disruption to services roughly 12,000 weekly benefit recipients relied on. New claims stalled in some states while the shared vendor stack was dark. No single state IT department “owned” every peer state in that blast radius. The coupling lived in the vendor platform.

These are not stories of one agency application dying alone. They are stories of a shared identity or vendor layer becoming unavailable, tightly coupled to citizen programs that look unrelated from the outside.

IT operations leaders feel this first: war-room time spent guessing downstream exposure. CISOs and GRC leads feel the evidence gap when oversight asks what else was in the path. Program and service-delivery leads feel the constituent impact while ownership of the shared layer sits elsewhere. Procurement and vendor-management leads feel it when multi-jurisdiction platforms fail without a clear dependency map in the contract file.

Why This Layer Is Under-Mapped in Government IT

Asset lists and CMDB CI records still follow org charts: benefits agency, tax agency, courts. Shared identity, multi-program vendor hosts, and integration buses often sit with a state CIO office, a shared-services unit, or an external provider. The teams that feel citizen pain are not always the teams that change the shared layer last.

Static architecture decks and spreadsheet “source of truth” files age the moment any one team ships a change. When an incident hits, neither side of the dependency has a current view of the other’s exposure. That is the same stale-map failure mode other regulated industries hit when corporate and plant systems share middleware nobody keeps joined to business services.

Service definitions still need an owner. In ViVID™, which applications and sites compose a named citizen service are supplied by the agency (manually, spreadsheet, or architecture tools). Once those definitions exist, discovery-sourced dependency maps can be built and refreshed on high-frequency discovery cycles so the picture of infrastructure under those services does not depend on the last PowerPoint export.

Why Incidents Drag On Without a Map

Uptime monitoring for essential services answers whether a service endpoint is reachable. It does not, by itself, list every other citizen process that shares the same SSO, vendor host, or integration hop. Without that chain, “no estimated time for resolution” is often the honest public line. Operators cannot yet say which downstream programs are safe to keep open and which must stay paused until the shared system recovers. Duration becomes partly a mapping problem, not only a restore problem.

Blast radius analysis for government IT is the ability to walk from a failing shared CI to the citizen-facing services and agency owners in its path before or during the event. Change impact works the same direction in reverse: before a maintenance window on a shared identity cluster, show which portals and batch jobs sit downstream.

Explore how Trusted Runtime Truth turns shared-infrastructure relationships into operational context agencies can defend.

The Compliance and Accountability Stakes

Asset audit and tracking work asks whether shared systems are recorded correctly for FISMA-oriented controls, NIST-aligned inventories, and budget reporting. Dependency mapping asks a second question regulators and legislative oversight increasingly press: what does this system connect to, and who else is affected if it fails? An asset row cannot answer that. A service map with relationship history can.

FedRAMP, CJIS, FISMA, and NIST frameworks (and state data-sharing agreements) are organizational and authorization control regimes. Mentioning them here is awareness of the evidence ask, not a claim that any product “certifies” infrastructure or replaces agency authorization packages. Legal and compliance teams should review any statutory wording before publish. The operational point stands without a statute quote: incident reviews and audits move faster when IT can show the citizen-process path, not only the CI label.

GRC and CISO stakeholders need that path for scope. Program leaders need it for constituent messaging. IT ops needs it to stop serial phone trees across agencies that do not share a help desk.

Where to Start: Mapping the Backend-to-Citizen-Service Path

Start with a short inventory of shared coupling points, then join them to named citizen services:

1. Identity and SSO that multiple citizen applications require before any transaction runs.
2. Vendor-hosted platforms that serve more than one program, department, or jurisdiction from a shared backend.
3. Integration middleware and data-exchange links that move data between agencies or between state and federal systems.
4. Incident runbooks tested against that shared chain, not only against department-owned application lists.

Virima’s place in that work is shared-infrastructure dependency visibility. Discovery populates and refreshes CIs. The CMDB holds relationships and audit history of what changed and what it touched. ViVID™ builds service dependency maps once service composition is defined, so impact paths run from a failing shared component to the citizen services that depend on it. That supports blast-radius and change-impact views for IT ops, compliance, and program leadership. Discovery programs and uptime monitoring serve different jobs and stay in place alongside service mapping. Integrations with ITSM platforms such as ServiceNow, Jira Service Management, Ivanti, HaloITSM, Xurrent, Hornbill, and TeamDynamix keep the same dependency picture inside the tools agencies already use for tickets and change (all integrations).

Shared Backends Decide How Far Citizen Outages Travel

The outages that lock people out of services they treat as unrelated often start in shared identity, vendor, and integration systems underneath, not inside one agency’s application code. They last longer when nobody mapped which citizen-facing processes those systems fed before the incident forced the question. Service mapping for government and public sector is the discipline of keeping that chain visible across org charts citizens never see.

See how Virima maps dependencies between shared backend systems and the citizen-facing services they support on ViVID™ Service Mapping, then request a demo to walk your identity, vendor, and integration paths with your team.

Frequently Asked Questions