CISA ZTMM User Inventory: Meeting OMB M-22-09 ICAM Requirements for Local Application Account Management

Local Application Accounts Are Still the ICAM Blind Spot

Local Application Accounts Are Still the ICAM Blind Spot

Most civilian agencies do not fail at Zero Trust identity because they lack an enterprise identity provider. They fail because too many mission applications still maintain their own user stores, their own administrator accounts, and their own offboarding logic. Those accounts sit outside the agency IdP, outside regular reconciliation, and often outside meaningful leadership visibility.

That is the user inventory problem. It is not a spreadsheet problem. It is an ICAM control problem, a FISMA reporting problem, and a procurement problem. When application-specific accounts are not centrally known, agencies cannot consistently enforce MFA, lifecycle controls, privileged access review, or account disablement after a user changes role or leaves government service.

Civilian CISOs and IT directors are solving this under real constraints: continuing resolution budget uncertainty, lean identity teams, legacy applications with brittle integrations, and acquisition timelines that do not always line up with Zero Trust deadlines. The practical starting point is not another policy memo. It is a defensible baseline of where local accounts exist, who owns them, which are privileged, and what the migration path is to enterprise ICAM.

What OMB M-22-09 and CISA ZTMM Require

OMB M-22-09 sets the federal direction clearly: agencies must move toward enterprise ICAM capabilities that support centralized identity management, phishing-resistant MFA, and consistent access enforcement across applications. Section III.B emphasizes comprehensive identity capabilities, while Section IV drives agencies to plan for eliminating or consolidating local and application-specific accounts as part of Zero Trust modernization.

CISA Zero Trust Maturity Model 2.0 gives agencies the maturity language to measure that work. In the User pillar, Advanced maturity expects automated discovery and continuous inventory of user accounts, identities, and access rights across on-premises and cloud environments. Optimal maturity expects that inventory to feed centralized identity providers and policy enforcement with real-time visibility.

FISMA adds the accountability layer. If local accounts are not inventoried, reviewed, and tied to authorization boundaries, the agency has weak evidence for access control implementation. FedRAMP matters because procurement can either fix this pattern or make it worse. New SaaS and cloud acquisitions should require federation, SAML or OIDC support, administrative account visibility, logging, and inventory APIs before the system becomes another identity silo.

CISA highlighted federal user inventory gaps again in its 2024 ZTMM updates, and OMB reinforced centralized identity consolidation in 2024 reporting guidance. The direction has not changed. Agencies need fewer unmanaged local accounts and better evidence that remaining exceptions are known, owned, and on a migration path.

The Diagnostic: Can You Name Every Local Account?

The first AISE diagnostic question in this capability is direct: Do you have a plan to decommission or centrally manage, via IdP or ICAM, local application accounts? That is the anchor question because it separates awareness from execution. Knowing that local accounts exist is not enough. The agency needs a plan, an owner, a target architecture, and a funded sequence of migrations.

From there, the assessment moves into the operating details. Have all applications using their own user account management been identified for both non-administrative and administrative accounts? If not, the agency does not yet have a reliable user inventory. The blind spot may sit in legacy case management systems, low-code platforms, contractor-operated applications, or cloud tools procured outside the enterprise identity process.

The next question is whether the agency has an inventory of regular user accounts in the centrally managed IdP or ICAM platform. That inventory should connect to HR source systems, directory services, role data, and application access records. The same standard applies to privileged accounts. Privileged identities need distinct tagging, tighter review cycles, and clear ownership because their risk profile is different.

The more difficult question is whether all accounts in applications that still manage their own identities are listed in a central inventory and marked as regular or privileged. This is where many programs stall. The enterprise IdP may be clean, but the unmanaged application tier still contains shared admin accounts, dormant contractor IDs, service accounts with human-like privileges, and accounts for users who have long since moved roles.

The final maturity test is automation. If the inventory depends on annual data calls and manually maintained spreadsheets, it will age out quickly. Agencies need recurring feeds from application logs, directories, HR systems, privileged access tools, ticketing platforms, and cloud control planes. Manual review still has a role, but discovery cannot be manual forever.

What AISE Scoring Means for User Inventory

AISE produces separate maturity scores for CISA ZTMM and DoD ZTA CoA from a single assessment. For civilian agencies, the primary value is the CISA ZTMM maturity score mapped to OMB M-22-09 requirements, with the OMB implementation gap presented cleanly for leadership reporting. The DoD ZTA CoA score is available as additional context, especially for agencies working with shared service providers, defense-adjacent systems, or contractors that support both environments.

At Maturity Level 1, the agency has a strategic foundation at best. There may be an enterprise IdP, but local application accounts are not fully discovered, privileged accounts are inconsistently tagged, and migration planning is fragmented. Leadership may know the issue exists, but the evidence base is thin.

At Maturity Level 3, the agency has operational control. Most applications are inventoried, local account exceptions are documented, regular and privileged accounts are separated, and account review processes are repeatable. Integration with the enterprise IdP is progressing, and new procurements increasingly require federation and identity data export.

At Maturity Level 5, user inventory is automated and continuously updated. Application accounts, IdP identities, privileged identities, HR status, and access review evidence feed a central view. Exceptions are time-bound. Policy enforcement is tied to the enterprise ICAM architecture. This aligns with the CISA ZTMM direction toward Optimal maturity.

Turning Scores Into Milestones

A maturity score is only useful if it drives decisions. For user inventory, we turn AISE results into milestones that program managers, CISOs, system owners, and procurement teams can execute.

• First, establish the authoritative application list and identify which systems maintain local user stores.

• Second, classify every account source as enterprise-managed, federated, local regular, local privileged, service account, or unknown.

• Third, assign each local account population to one of three paths: migrate to enterprise IdP, retain with approved exception, or decommission.

• Fourth, update procurement language so new systems support federation, role export, privileged account reporting, and logging from day one.

• Fifth, connect user inventory evidence to FISMA control reporting and FedRAMP package review where applicable.

This is how the score becomes management action. The point is not to create more reporting burden. The point is to make the existing reporting reflect the actual identity environment.

ROM Timelines for Civilian Agencies

Timelines depend on application count, system ownership, contract structure, and the condition of the current ICAM stack. Still, agencies need realistic ROM planning numbers for budget and leadership conversations.

For a small bureau or component with fewer than 50 applications, a credible baseline can often be built in 6 to 10 weeks if application owners are available and identity logs are accessible. Moving from a Level 1 posture to a Level 3 operating model usually takes 4 to 8 months, driven by application discovery, account classification, privileged account tagging, and migration planning.

For a mid-size agency with 100 to 300 applications, the baseline often takes 10 to 16 weeks. Moving to Level 3 commonly takes 8 to 14 months because of contract dependencies, legacy application constraints, and system owner coordination. Moving toward Level 5 generally requires 18 to 30 months because automation must be engineered across HR, IdP, PAM, SIEM, ticketing, and application platforms.

For large cabinet-level environments, agencies should expect phased execution across portfolios. A first baseline may take 90 to 120 days for priority systems, with full portfolio discovery running longer. The right approach is to sequence by mission impact, privileged access concentration, internet exposure, and authorization boundary priority. Under continuing resolutions and constrained staffing, portfolio sequencing matters more than broad unfunded ambition.

Federal Scenario: From Spreadsheets to Central Identity Evidence

In one civilian agency environment, the enterprise identity team had a mature directory service and MFA coverage for core systems, but more than 70 mission applications still maintained separate user accounts. Some were legacy applications. Some were contractor-operated platforms. Some were SaaS tools acquired before federation requirements were standard in procurement language.

The agency had three different spreadsheets tracking application users, none of which matched HR records or the enterprise directory. Privileged accounts were mixed with regular accounts. Several applications had local administrator accounts tied to former contractor staff. No one was hiding the issue. The problem was that no team owned the full identity picture across system boundaries.

The first step was to define the application inventory and classify account management patterns. The second step was to tag local privileged accounts and identify orphaned or inactive accounts. The third step was to update procurement templates so future acquisitions required SAML or OIDC federation, administrative account reporting, audit logs, and exportable account data. The fourth step was to connect priority applications to the agency IdP and document exceptions for systems that needed more time.

Within two quarters, leadership had a defensible CISA ZTMM user inventory baseline and a ranked migration plan. The agency did not solve every legacy identity issue immediately. No serious practitioner expects that. But it moved from fragmented evidence to managed execution, and that changed the quality of FISMA reporting and Zero Trust governance discussions.

Get a Defensible User Inventory Baseline

User inventory is one of the fastest ways to expose whether Zero Trust ICAM is real or only documented at the architecture level. If local application accounts remain unmanaged, the agency cannot make strong claims about centralized identity enforcement, privileged access control, or user lifecycle management.

AISE gives civilian agencies one assessment with two scorecards: a CISA ZTMM maturity score mapped to OMB M-22-09 and a separate DoD ZTA CoA score for additional context. For agency leadership, the result is a clean view of current maturity, OMB M-22-09 implementation gaps, and the next milestones to fund and execute.

To get your AISE maturity baseline for user inventory, visit zephon.tech/zt or contact defend@zephon.tech.