Non-Person Entities (NPE) and Federal ICAM Guide: Governing Devices, Services and Automation in Government

US federal and defence policy has required agencies to manage the identities of devices, services and automated tools for years, yet most ICAM programmes still treat non-person entities as an afterthought behind PIV cards and user accounts. In federal and DoD language, a non-person entity (NPE) is what the commercial world calls a non-human identity: servers, endpoints, applications, service accounts, robotic process automation bots, cloud services and now AI agents. OMB M-19-17 directs agencies to manage the digital identity lifecycle of devices, NPEs and automated technologies, and the DoD Zero Trust capability set includes specific activities for NPE certificates and integrating NPEs with the enterprise identity provider. This guide explains what counts as an NPE, how NPEs fit the FICAM services model and DoD ICAM, what the policies actually require, and how to build an NPE programme with inventory, sponsorship, credentials and monitoring. It is for federal and defence ICAM teams, system owners, integrators and contractors working to these requirements. The wider DoD framework is covered in the DoD Zero Trust Strategy and Reference Architecture Guide.

Key takeaways

• NPE is the federal term for non-human identity. CNSSI 4009-2022, quoted in the NIST glossary, defines it as an entity with a digital identity that acts in cyberspace but is not a human actor, covering devices, software objects and information artefacts.
• The requirement is lifecycle management, not just authentication. OMB M-19-17 requires agencies to keep NPE identities distinguishable, auditable and consistently managed, and to bind, update, revoke and destroy their credentials.
• Every NPE needs a human sponsor. The DoD Enterprise ICAM Reference Design requires accountability for NPE behaviour to link, directly or through a chain, to a person or organisation sponsor, who also performs access reviews.
• DoD Zero Trust makes NPEs concrete. Activities 2.1.2, 2.1.3 and 2.3.6 call for NPE certificates through the enterprise PKI, integration of devices and service accounts with the enterprise IdP, and retirement or risk-based exception for NPEs that cannot comply.
• Service accounts and API keys are where programmes fail. Devices get certificates through endpoint management; scripts, integrations and contractor-held keys are where federal incidents keep starting.

What counts as a non-person entity

The NIST CSRC glossary gives the definition from CNSSI 4009-2022, adapted from DHS OIG 11-121: "An entity related to information technology with a digital identity that acts in cyberspace, but is not a human actor." It notes this can include organisations, physical devices, virtual or logical software objects and information artefacts. NIST SP 800-162 (attribute based access control) and SP 800-207 (Zero Trust Architecture) also use the NPE term for subjects that are not people.

The DoD Enterprise ICAM Reference Design is more operational. It states that "NPEs include physical devices, systems, and processes that are assigned identifiers", and lists categories that may overlap.

The same document requires that NPEs interacting across the DoD enterprise have an identifier unique across the enterprise, while narrower NPEs may use identifiers unique to a component, community of interest or network layer. Attributes may include organisational information, host name, IP address or fully qualified domain name. For commercial readers, the mapping is direct: see the NHI Ownership Guide and the Machine Identity, PKI and Certificate Lifecycle Guide.

What federal policy requires

Two points are often missed. First, M-22-09 focuses on people and devices, so agencies that track only M-22-09 progress can show green on identity while service accounts remain unmanaged. Second, the FICAM Architecture's Privileged Access Management service covers elevated accounts but does not say explicitly whether it covers non-person accounts, so agencies need to state that scope themselves. See the US Federal Cybersecurity Executive Orders Guide for the wider policy chain.

NPEs in the DoD Zero Trust capability set

The DoD Zero Trust Capabilities and Activities document turns NPE management into activities that components report against.

• Capability 1.5 Identity Federation and User Credentialing: credentials bound to DoD person, device and NPE identities, managed through identity lifecycle processes and integrated with the IdP and identity management solution.
• Capability 1.9 Integrated ICAM Platform: enterprise identity management and PKI systems that track user and NPE identities, with credential management, identity governance, access management and a trusted root CA.
• Activity 1.8.1 Single Authentication: users and NPEs authenticated at least once per session.
• Activity 2.1.2 NPE/PKI, Device under Management: X.509 certificates for managed devices through the enterprise PKI, and NPEs assigned in the PKI and/or IdP systems.
• Activity 2.1.3 Enterprise IDP Pt1: integrate NPEs such as devices and service accounts with the enterprise IdP; NPEs that cannot be integrated are retired or granted a risk-based exception.
• Activity 2.1.4 Enterprise IDP Pt2: add dynamic NPE attributes such as location and usage patterns to the IdP profile.
• Activity 2.3.6 Enterprise PKI Pt1: expand the enterprise PKI to NPE and device certificates; NPEs and devices that cannot support certificates are retired.
• Capability 2.4 Remote Access: authorised and authenticated users and NPEs reach data, applications, assets and services remotely under a deny-device-by-default policy.
• Activity 3.4.5 Enrich Attributes for Resource Authorization Pt1: build a basic risk posture for users, NPEs and devices from UEBA, micro-segmentation, DLP and DRM attributes.

The "retire or exception" wording in 2.1.3 and 2.3.6 is the practical lever: it forces a decision about legacy NPEs that cannot use certificates or IdP authentication, instead of leaving them in place indefinitely.

Mapping NPEs onto the FICAM services model

The reference design's NPE creation flow is a good template: a sponsor (a person or another NPE) initiates creation, the identifier is either native (such as a device serial number) or assigned by an enterprise, component or local repository, the sponsor configures the NPE, and its attributes are recorded and updated when configuration changes. See the Zero Trust Identity Guide.

Credentials for NPEs: choosing the right type

• Enterprise PKI certificates: the default for managed devices and servers in DoD activities 2.1.2 and 2.3.6. Prefer hardware-protected keys (TPM or HSM), which the Federal PKI maps to AAL3 for device certificates. Automate enrolment and renewal, for example with SCEP, EST or ACME internally. See the IoT and Device Certificate Provisioning (EST, SCEP) Guide.
• Federated workload identity: for cloud workloads, managed identities and OIDC federation replace stored keys, and fit the "integrate with enterprise IdP" intent where the IdP can issue or trust workload tokens.
• Service accounts in the directory: where an application can only use a username and password, use managed service accounts with automatic rotation or vault the secret, and register a sponsor. These are prime candidates for risk-based exceptions with dates.
• API keys and static secrets: the weakest option and the one most often leaked. Use only where nothing else is supported, with scope limits, expiry and monitoring. See the API Key Management Guide.
• AI agents and RPA: M-19-17 explicitly names RPA and AI tools as automated technologies. Give each agent or bot its own identity rather than letting it reuse a human's PIV-derived session or a shared service account. See the Zero Trust for AI Agents Guide.

Decision guidance: civilian agencies, DoD and contractors

• Civilian agencies: anchor the NPE programme on M-19-17 and the FICAM services model, and use CISA's Zero Trust Maturity Model for device and identity pillar maturity. M-22-09 progress alone does not show NPE coverage. See the CISA Zero Trust Maturity Model Guide.
• DoD components: track the NPE activities explicitly in Zero Trust execution plans, and use the ICAM Reference Design's categories and sponsor model as the inventory schema.
• Defence industrial base and contractors: CMMC and NIST SP 800-171 require identification and authentication of devices and processes acting on behalf of users. Contractor-held credentials to government systems are NPEs of the agency and must be inventoried, sponsored and revocable by the agency, not just the contractor. See the NIST SP 800-171 and CMMC 2.0 Guide.
• Small agencies or bureaus: start with the highest-risk NPE classes (privileged service accounts, cloud keys, CI/CD credentials) rather than trying to certificate-enable every device at once.
• Large departments: federate NPE inventories from component repositories into one view with consistent identifiers and sponsor attributes, as the reference design's enterprise-unique identifier rule implies.

How to implement an NPE programme

1. Define scope and schema. Adopt the DoD categories (devices, virtual machines, information systems, services, spawned processes, non-traditional systems) and a minimum attribute set: identifier, category, sponsor, owning system and ATO, credential type, privilege level, creation and last-used dates.
2. Discover. Pull devices from CDM and endpoint management, service accounts from directories and cloud tenants, certificates from PKI and certificate transparency, and secrets from vaults and code scanning. Expect the service account and secret counts to be far higher than records suggest.
3. Assign sponsors. Every NPE without a sponsor is either assigned one within a set period or disabled. Sponsors perform access reviews, as the reference design requires.
4. Pick credential targets by category. Certificates for devices and servers, federation for cloud workloads, managed or vaulted service accounts for legacy applications, and documented exceptions for the rest.
5. Pilot and test. Migrate one system's NPEs end to end, running old and new credentials in parallel briefly, monitoring authentication logs, then disabling the old credential before deletion so rollback is a re-enable.
6. Integrate with governance. Add NPEs to recertification campaigns, link deactivation to decommissioning and ATO expiry, and feed NPE attributes into authorisation and analytics, matching activities 2.1.4 and 3.4.5.
7. Handle exceptions formally. Record each NPE that cannot meet the target with a risk acceptance, compensating controls and an expiry date, in line with the retire-or-exception rule.

Detection and measurement

• Authentication telemetry: log every NPE authentication at the IdP, PKI validation points and cloud control planes, and baseline normal source, time and volume. Alert on interactive logons by service accounts and on NPE credentials used from new networks. See the Detection Engineering for Non-Human Identities Guide.
• Logging maturity: civilian agencies can align NPE event collection with OMB M-21-31 logging tiers. See the OMB M-21-31 Logging Maturity Guide.
• Secret exposure: scan agency and contractor repositories, and monitor for agency keys appearing in public code.

Framework mapping

Common failure patterns

• Devices only. The programme certificate-enables endpoints and reports success, while service accounts, CI/CD credentials and cloud keys remain unmanaged.
• Contractor-held keys outside agency control. In the CISA Private-CISA GitHub Leak, a contractor's public repository held AWS GovCloud administrative keys, Artifactory credentials and Entra ID SAML certificates for about six months, after push protection had been disabled.
• Vendor NPEs with reach into agencies. In the BeyondTrust Breach, a stolen vendor infrastructure API key let a state-sponsored actor reach Treasury workstations through a remote support service. Third-party NPEs with access to agency systems need the same inventory and revocation plan as internal ones.
• No sponsor, no decommissioning. NPEs outlive their projects and owners because nothing ties their deactivation to system retirement or ATO expiry.
• Shared accounts for automation. RPA bots and scripts run under a shared service account or a person's credentials, so activity is neither distinguishable nor auditable, which is exactly what M-19-17 requires.
• Public data keys treated as harmless. Developer API keys for federal data services published in code were picked up and used by AI agents, as described on the OpenAI Agents and US Government Websites page, leaving activity attributed to the key owners.

Practitioner checklist

• Adopt the CNSSI 4009 definition and DoD NPE categories in policy, and state that NPEs include service accounts, API keys, RPA and AI agents.
• Build an NPE inventory with enterprise-unique identifiers, sponsors, owning system and credential type.
• Require a sponsor for every NPE and include NPEs in access recertification.
• Issue enterprise PKI certificates to managed devices and servers, with hardware-protected keys where possible.
• Integrate service accounts and workloads with the enterprise IdP or federation; vault and rotate what cannot be integrated.
• Record risk-based exceptions with compensating controls and expiry dates; retire NPEs that cannot comply.
• Tie NPE deactivation to decommissioning and ATO expiry.
• Bring contractor and vendor credentials to agency systems into the inventory and revocation process.
• Log and baseline NPE authentication, and alert on interactive use and new sources.

Standards and references

• OMB: M-19-17 Enabling Mission Delivery through Improved Identity, Credential, and Access Management
• DoD CIO: Zero Trust Capabilities and Activities
• DoD CIO: DoD Enterprise ICAM Reference Design
• GSA: Federal ICAM (FICAM) Architecture
• NIST CSRC: Glossary, Non-Person Entity
• OMB: M-22-09 Moving the U.S. Government Toward Zero Trust Cybersecurity Principles
• GSA: Federal PKI overview
• NIST: SP 800-53 Rev. 5

Related NHI Mgmt Group resources: DoD Zero Trust Strategy and Reference Architecture Guide · Smart Card and PIV/CAC Authentication Guide · NHI Ownership Guide · Zero Trust Identity Guide · FedRAMP Guide