Non-Human Identity Security: Why Your CMDB Must Track Service Accounts, API Keys, and Machine Identities

What Are Non-Human Identities?

A non-human identity is any credential that a machine, application, or automated process uses to authenticate and operate within your IT environment. These are not user accounts. No person logs in with them each morning. Instead, they run silently in the background, executing jobs, calling APIs, and accessing sensitive data around the clock.

Common types of non-human identities include:

• Service accounts: accounts created in Active Directory or a local OS to run scheduled tasks, services, and background processes
• API keys: static credentials that applications use to authenticate with external or internal services
• SSH keys: cryptographic key pairs that grant remote access to servers and infrastructure
• OAuth tokens and JWT credentials: short-lived or long-lived tokens used in application-to-application communication
• TLS and SSL certificates: machine certificates that authenticate servers and encrypt communications
• Cloud IAM roles and workload identities: permissions assigned to compute instances, Lambda functions, or container workloads in AWS and Azure

The challenge with all of these is that developers or automation pipelines provision them quickly, and almost no one tracks them in a central inventory. When someone creates a service account to support a new integration, it rarely makes it into the CMDB as a configuration item. When a developer generates an API key for a third-party tool, they usually drop it into a config file or a secrets manager with no relationship record linking it to the systems it touches.

That invisibility is where the risk begins.

Why Non-Human Identity Security Is a Growing Priority

According to CyberArk’s 2025 Identity Security Landscape report, machine identities now outnumber human identities by more than 80 to 1 in most enterprise environments. That ratio reflects the scale of automation, cloud adoption, and application proliferation that modern IT teams manage. It also reflects the scale of the governance gap. Most identity programs target human accounts. Non-human identity security often gets little more than a periodic password rotation policy, if anything at all.

This gap has real consequences. Several high-profile breaches in recent years started with an unrotated API key or an over-privileged service account that no one realized was still active. When attackers compromise a machine credential, they often gain lateral movement capabilities that are much harder to detect than a compromised human account. Machine-to-machine traffic looks normal. Alerts rarely fire. The breach can persist for weeks.

The Cloud Security Alliance’s Non-Human Identity Governance white paper reinforces this finding, noting that NHI sprawl across enterprise environments is accelerating alongside the adoption of agentic AI systems. As AI agents spawn sub-agents and automation workflows multiply, the number of machine credentials in any given environment grows faster than security teams can track manually.

The core problem is that non-human identity security requires asset visibility before it can work. You cannot rotate credentials you do not know exist. You cannot detect anomalous service account behavior if you do not know which accounts are legitimate. And you cannot assess the impact of a compromised API key if you have no record of which systems it authenticates to. That is precisely where CMDB coverage becomes critical.

What Your CMDB Should Track for NHI Governance

Most CMDBs track servers, workstations, applications, and network devices reasonably well. Fewer track the identity layer sitting on top of those assets. For non-human identity security to be effective, your CMDB needs to extend its coverage to include the following:

Service Accounts

Each service account should exist as a configuration item in your CMDB, linked to the service or application it supports. Key attributes include the account name, the system it runs on, the owner or responsible team, permission scope, and the date of its last password change. Virima’s Active Directory monitoring capabilities surface these attributes automatically during each discovery cycle, so your CMDB reflects the current state of every service account without requiring manual updates.

API Keys and Tokens

Developers often create API keys and store them in application configs, environment variables, or secrets managers. Your CMDB should include a record of each key with its purpose, the systems it authenticates to, its creation date, and its expiration date if one exists. Without this record, you have no way to identify keys that someone generated for a project that no longer exists.

SSH Keys

SSH keys provide direct access to servers and infrastructure. They tend to be long-lived, and teams share them across projects. A CMDB record for each SSH key pair should capture the associated server or server group, the authorized user or process, and whether a human or an automation pipeline generated the key. Untracked SSH keys in a hybrid environment frequently become persistent access paths for attackers.

Machine Certificates

TLS and SSL certificates require the same CMDB treatment as any other machine identity. Your CMDB should track each certificate with its subject, issuer, associated system, expiry date, and renewal owner. For organizations managing certificates across web servers, APIs, and internal services, this quickly becomes complex. Virima’s IIS SSL/TLS certificate discovery capability surfaces these certificates as part of discovery, giving teams the inventory foundation they need before certificates expire unnoticed.

Cloud Workload Identities

In AWS and Azure environments, compute instances, serverless functions, and container workloads are assigned IAM roles and managed identities. Your CMDB should link these cloud workload identities to the resources they govern Virima’s API-based discovery covers AWS and Azure, pulling these relationships into the CMDB alongside the compute and storage assets they protect. The guide to hybrid cloud CMDB and digital transformation covers how identity records fit into broader cloud asset governance.

Network-Connected Devices and IoT

Beyond servers and cloud workloads, network-connected devices — including IoT sensors, OT systems, and edge devices — often carry embedded credentials that teams rarely change or review. Virima’s network device discovery surfaces these assets as configuration items, giving security teams visibility into the identity layer that sits on top of physical and virtual network infrastructure.

How Discovery-Driven CMDB Coverage Surfaces NHIs

Manual inventory processes were never designed to track non-human identities at scale. Developers create service accounts without logging them centrally. Developers generate API keys in self-service portals. SSH keys accumulate on servers with no central registry. By the time a security team tries to build an NHI inventory by hand, the list is already incomplete.

High-frequency discovery cycles change that equation. Rather than asking people to self-report machine identities, discovery tools query the systems where those identities live. Virima’s hybrid IT discovery covers on-premises and cloud environments through agentless scans, agent-based probes, and API-based queries. This approach surfaces service accounts in Active Directory, certificate records from IIS and other web servers, and IAM role assignments from AWS and Azure. It also identifies the relationships between those identities and the assets they serve — which is what transforms a flat NHI list into actionable CMDB data.

Active Directory is a particularly rich source. Every AD object carries attributes that CMDB teams can use: account creation date, last logon, group membership, and password age. Virima’s Active Directory monitoring capabilities pull this data into the CMDB automatically, so teams see not just the service accounts that exist, but which ones have not authenticated in months and which ones carry excessive privilege relative to their documented purpose.

Discovery also catches drift. When someone modifies a service account, expands its group memberships, or changes its password policy, those changes show up in subsequent discovery cycles. That gives security teams a before-and-after record, rather than a snapshot taken once during an audit.

For a broader look at what happens when a CMDB lacks discovery coverage, A CMDB Without Discovery Is Just a Database is a useful starting point. The same principle applies directly to identity data: without discovery, your NHI inventory is a guess.

NIST’s guidelines on enterprise identity management (SP 800-63) provide a framework for thinking about non-person entities (NPEs) as a distinct identity class that requires its own lifecycle policies. Aligning your CMDB NHI governance model to these guidelines helps security and GRC teams demonstrate that machine identity controls are built on recognized standards.

NHI Visibility and Change Risk: The Connection Your Team May Be Missing

• Change risk analysis in most organizations focuses on infrastructure: what servers will restart, what applications depend on this patch, what teams need to be notified. Service accounts and API keys rarely make it into the pre-change impact assessment. That is a significant gap.
• Consider a common scenario: a team upgrades a middleware application and rotates the database connection string as part of the change. The application itself comes back cleanly. But three downstream services, each using their own service account with embedded credentials pointing to the old connection, start failing silently. Without a CMDB record linking those service accounts to the middleware CI, no one predicted the dependency.
• This is where ViVID™ service maps extend the value of NHI tracking. When service accounts and API keys exist as configuration items in the CMDB, you can include them in service dependency maps. A ViVID service map for a business-critical application can show not only the servers and databases it depends on, but also the service accounts and credentials that the application uses to authenticate to each layer. That makes change impact assessment more complete and reduces the risk of post-change failures caused by credential dependencies no one accounted for.
• The same principle applies when AI agents run in your environment. As the guide to CMDB questions before running AI agents on ServiceNow explains, agents executing automated actions need to know which identities and credentials govern each asset they interact with. A CMDB that tracks NHIs alongside CIs gives those agents the full context they need to act safely.
• The same logic applies to decommissioning. When a server is retired, the service accounts running on it need to be reviewed for dormancy or reassignment.A CMDB with NHI coverage supports that review automatically, because it already records the relationships.

Best Practices for NHI Governance in Your CMDB

Getting non-human identity security right in a CMDB context requires more than adding a few new CI classes. It requires process discipline and discovery coverage that keeps those records current. Here are the practices that tend to make the biggest difference:

1. Define NHI as a First-Class CI Type

Add service accounts, API keys, certificates, and cloud workload identities to your CMDB schema as distinct CI types. Each type should have its own attribute set, ownership field, and relationship class. This structures the inventory in a way that supports both security review and operational use.

2. Assign an Owner to Every NHI

Every machine identity needs a human owner. That owner handles rotation, access review, and decommissioning once the credential no longer serves a purpose. CMDBs that lack an ownership field for NHIs quickly accumulate orphaned credentials with no accountable party.

3. Map NHIs to the Services and Assets They Support

A service account record in isolation tells you little. Link each NHI to the CIs it authenticates to and the services that depend on it. This relationship layer is what enables impact analysis when a credential is compromised or needs to be rotated. The ITOM capabilities in Virima make these dependency links visible across your full IT operations layer, not just within a single application silo.

4. Include Credential Rotation Dates in Discovery Cycles

Discovery-driven CMDB updates should capture password age and certificate expiry dates during each scan cycle. Flag NHIs whose credentials have not been rotated within your defined policy window. This turns discovery into a lightweight compliance check, not just an inventory refresh.

5. Include NHIs in Change and Decommission Workflows

Integrate NHI records into your change management process. When a server is decommissioned, trigger a review of all service accounts linked to that CI. When you retire an API integration, flag its associated API keys for revocation. This prevents credentials from persisting long after the systems they were created for are gone.

6. Review Privilege Scope Against Actual Use

Teams create many service accounts with broad permissions and never trim them. Use discovery data to compare the permissions granted to each NHI against the actual access patterns observed during scans. Accounts with domain admin membership that only need to run a single scheduled task are a common example of privilege creep. Addressing this is a core part of cybersecurity asset management at the identity layer.

7. Align NHI Governance to Your ITAM Lifecycle

Non-human identities have a lifecycle just like hardware and software assets. Teams create, modify, and eventually decommission them. Aligning NHI governance to your IT Asset Management lifecycle process means credentials get reviewed at the same checkpoints as the assets they serve. That alignment prevents orphaned accounts from persisting after you retire a server or decommission an application.

How Virima Supports Non-Human Identity Security

Virima delivers Trusted Runtime Truth across your IT environment, and that includes the identity layer. The platform’s high-frequency discovery cycles surface service accounts from Active Directory, certificates from IIS and web servers, and cloud IAM assignments from AWS and Azure as part of standard operation. Virima populates these records as configuration items with relationship links to the assets and services they support.

The Cybersecurity Asset Management capability extends this further. It maps NHIs alongside hardware assets and software installations, and connects them to NVD vulnerability data so teams can see which machine identities are associated with assets carrying active CVEs. When a server has an unpatched vulnerability and a service account with domain admin rights, those two facts need to appear in the same view. Virima makes that connection. For a broader picture of how asset management and security intersect, the guide on 6 ways your ITAM is key to cybersecurity is worth reading alongside this one.

ViVID™ service maps then visualize the dependencies. Virima can represent a service account as a dependency chain: it runs on an application server, authenticates to a database, and answers calls from an upstream API gateway. That map shows change teams exactly what a credential rotation will affect before they execute it. For a deeper look at how hybrid cloud environments factor into this, the guide on hybrid cloud security for asset managers covers how machine identity governance fits into a broader cloud security program.

Virima integrates bidirectionally with ServiceNow, Ivanti, Halo, Jira Service Management, and Xurrent. Virima can push the NHI records and relationships it discovers into these platforms, keeping your ITSM-side CMDB current with the same identity data your security team uses. That removes the need to maintain separate inventories across tools.

For security and compliance teams managing NHI governance against frameworks like SOX, HIPAA, or ISO 27001, the 7 reasons to invest in a cybersecurity asset management tool outlines how discovery-driven CMDB coverage supports audit readiness and continuous compliance across your identity and asset inventory.

Common Challenges When Tracking NHIs in a CMDB

Most teams that attempt NHI tracking in their CMDB hit a few predictable obstacles. Understanding them ahead of time helps you plan for them.

Incomplete Discovery Coverage

If your discovery only covers servers and workstations, it will miss the identity layer entirely. Extending discovery to include Active Directory objects, cloud IAM APIs, and certificate stores requires configuration work upfront. The post on why a CMDB without discovery is just a database explains why this foundation matters so much — and what teams can do about it.

No Ownership Model for Machine Identities

Developers or automation scripts often create service accounts and API keys, and no one formally owns them. Without an ownership model in your CMDB schema, NHI records accumulate with no accountable team. Building this model early, even informally, prevents the problem from compounding.

Stale Records from One-Time Imports

A one-time import of service accounts from Active Directory gives you a starting point but not a maintained inventory. As teams create, modify, and delete accounts, that import becomes stale quickly. Discovery-driven refresh cycles keep the NHI inventory current without requiring manual updates. NIST’s guidance on digital identity lifecycle management makes clear that identity records must reflect the current state of each identity, not a historical snapshot.

Credential Data Sitting Outside the CMDB

Teams often store API keys and secrets in secrets managers, environment variables, or code repositories rather than in the CMDB. The CMDB does not need to store the credential value itself. You need to build governance workflows — rotation schedules, access reviews, decommission triggers — on top of the CMDB data. Keeping that distinction clear makes the governance model practical without creating a security risk.

Lack of Enforcement After Discovery

Even with a complete NHI inventory, teams often struggle to act on what they find. Governance workflows — rotation schedules, access reviews, decommission triggers — need to be built on top of the CMDB data. Virima’s integration with ITSM platforms such as Halo, Jira Service Management, and Xurrent means that flagged NHI records can feed directly into ticket-based remediation workflows. The CMDB governance best practices guide for ServiceNow covers how to structure these enforcement workflows so that discovery findings translate into action rather than just reports.

Frequently Asked Questions

What is the difference between non-human identity security and privileged access management?

Privileged access management (PAM) focuses on securing and vaulting high-risk credentials, typically for human users or known service accounts. Non-human identity security is broader. It covers the full lifecycle of all machine credentials, including API keys, certificates, and cloud workload identities, many of which PAM tools do not track by default. A CMDB provides the inventory layer that PAM tools can then act on effectively.

How often should CMDB records for service accounts be refreshed?

Most organizations run discovery cycles on a scheduled basis ranging from daily to weekly, depending on the rate of change in their environment. For NHI records specifically, more frequent discovery is preferable because machine identities change quickly. The key is that discovery drives refresh cycles rather than manual processes, so the inventory stays current without depending on developers or admins to self-report changes.

Can Virima track API keys and secrets in the CMDB?

Virima tracks the metadata associated with machine identities, including service accounts and certificates discovered through Active Directory scans and IIS server queries. For API key governance, Virima surfaces the systems and applications that use API-based authentication as CIs, providing the relationship context needed for governance. Virima does not store credential values — teams should continue to use a dedicated secrets manager for secure credential storage.

What is identity sprawl and how does a CMDB reduce it?

Identity sprawl refers to the accumulation of machine credentials across an environment with no central inventory — credentials no one needs anymore but no one ever revokes. A CMDB reduces identity sprawl by making every NHI visible as a configuration item. When security teams can see which service accounts have not logged in recently, which API keys are past their rotation date, and which certificates are approaching expiry, they can take action on the sprawl rather than discovering it during an incident.

Your CMDB Is the Inventory Layer That NHI Governance Depends On

Non-human identities are not going away. Automation, cloud adoption, and agentic IT are all expanding the number of machine credentials your environment depends on. Security programs that govern only human accounts are increasingly exposed to breaches that start with a forgotten service account or an unrotated API key.

The answer is not a separate NHI management tool sitting next to your CMDB. It is a CMDB built on discovery-driven data that treats service accounts, API keys, and machine certificates as configuration items with the same rigor applied to servers and applications. When non-human identity security is grounded in CMDB data, your team can rotate credentials with confidence, assess change impact accurately, and detect orphaned accounts before they become breach vectors. For organizations that want to understand how all of these pieces connect at the operational level, the guide on ITAM and cybersecurity is a practical next step.

Virima gives your team the discovery coverage and CMDB structure to make that possible. From Active Directory service accounts to cloud IAM roles and IIS certificates, every machine identity becomes a visible, governed configuration item with a clear owner and a relationship map.