Why has NHI security become a board-level topic in 2025 and 2026?

Three converging forces. First, the NHI population has grown faster than the human identity population: every microservice, every CI/CD pipeline, every SaaS-to-SaaS integration, every cloud service, every container, and every automation script mints at least one identity and typically several. The asymmetry now sits at roughly 45-to-1 to 100-to-1 NHI-to-human in mainstream cloud-anchored enterprises and continues to widen. Second, the published breach reporting from the last several years repeatedly attributes high-impact incidents to compromised non-human credentials: leaked GitHub tokens, over-permissioned cloud IAM roles assumed by attackers, OAuth integration grants abused after a SaaS-vendor compromise, long-lived API keys exfiltrated from CI logs, service principal secrets reused across environments. Third, regulators and frameworks have caught up: NIST SP 800-53 Rev. 5 IA-9 names device and non-person entity authentication explicitly, NIST CSF 2.0 PR.AA-04 covers identities and credentials for authorised devices and services, ISO 27001:2022 A.5.16 and A.5.17 cover identity management and authentication information for the full identity population, PCI DSS v4.0 8.6 calls out application and system accounts, the EU Cyber Resilience Act Article 13 requires secure default configuration including authentication and credential management for non-human identities embedded in products, DORA Articles 9 and 11 cover ICT system identity and authentication controls across the financial services estate, and CISA Secure by Design names the goal of eliminating long-lived shared credentials. NHI security stopped being a niche identity-engineering concern and became a CISO-level posture requirement.

How does NHI security differ from IAM, PAM, CIEM, ISPM, and ITDR?

IAM (Identity and Access Management) is the prevention layer for both human and non-human identities. PAM (Privileged Access Management) is the elevation-and-control layer focused historically on privileged human accounts. CIEM (Cloud Infrastructure Entitlement Management) is the cloud-scoped entitlement analysis layer that maps which identities (human or non-human) can do what across cloud IAM policies and trust relationships. ISPM (Identity Security Posture Management) is the broader posture-management layer for the identity provider stack. ITDR (Identity Threat Detection and Response) is the detection-and-response layer for identity-targeted attacks. NHI security is the discipline anchored specifically on the non-human identity population: it inherits inventory expectations from CIEM (for the cloud IAM slice), pulls posture rules from ISPM (for the directory-side service account slice), pulls detection content from ITDR (for the attack-side signals), and adds the NHI-specific layers nothing else owns end-to-end: discovery across cloud IAM, secret managers, SaaS OAuth grants, CI/CD platforms, service meshes, container orchestrators, and federated workload identity together; classification by lifecycle (long-lived versus short-lived), by criticality, by data scope, by trust boundary; rotation cadence and rotation evidence; secret leakage detection (source code, build logs, configuration); ownership mapping (every NHI has a human owner of record); and lifecycle (creation, attestation, periodic review, deprovisioning) for non-human identities specifically. NHI security is the layer that finally makes the non-human population first-class in the identity programme rather than a secondary concern hidden behind the human IAM and PAM disciplines.

How does NHI security relate to SCA, SBOM, and software supply chain security?

NHI security and software supply chain security overlap on the build pipeline. Software Composition Analysis (SCA) and Software Bill of Materials (SBOM) work address the component lineage of the software the team ships: which open-source packages are pulled in, which versions, which known vulnerabilities those versions carry, which exploitability statements (VEX) the team has issued. NHI security addresses the identity lineage of the same pipeline: which identity authenticated the build, which identity signed the artefact, which identity pushed the container image, which identity invoked the deploy, which identity reads the secrets the runtime loads. The two disciplines reinforce each other. A compromised CI/CD identity can publish an unmodified SBOM that asserts a clean component tree against a deployable artefact the attacker has tampered with; a leaked deploy key can ship a vulnerable component into production even when the SBOM and VEX records say the version was sandboxed. Mature programmes run both as parallel layers under the wider software supply chain security operating record, with the engagement and finding lineage paired to the build, the artefact, and the runtime so an audit can reconstruct what the identity did, what the artefact contained, and what the runtime executed from one operating record.

What does an NHI security programme look like in practice?

A practical NHI programme runs in five layers. Layer 1 is discovery: enumerate every NHI across cloud IAM (AWS IAM users and roles, Azure service principals and managed identities, Google Cloud service accounts, OCI principals), every secret store (HashiCorp Vault, AWS Secrets Manager, Azure Key Vault, Google Secret Manager, CyberArk Conjur, Akeyless), every CI/CD platform (GitHub Actions, GitLab CI, CircleCI, Jenkins, Azure DevOps, GitHub App installations and PATs), every SaaS-side OAuth grant inventory and integration registry, every workload identity federation trust, every service mesh identity (Istio SPIFFE IDs, Linkerd identities, Consul service identities), every Kubernetes service account, every database connection account, every monitoring and scanner agent identity, every PAT and machine user across source control. Layer 2 is classification: tag each NHI by criticality (read-only versus mutation, low-data-scope versus high-data-scope, low-trust-boundary versus cross-trust-boundary), by lifecycle (long-lived versus short-lived versus ephemeral), by ownership (the human accountable for review), and by relationship (which service it serves, which environment, which build, which artefact). Layer 3 is governance: anchor each NHI against an NHI policy with rules for over-privileged grants, missing rotation evidence, long-lived secret without rotation cadence, no human owner of record, no periodic review record, OAuth grant with excess scope, federated workload identity with weak trust condition, signing key with no expiry, mTLS certificate with no renewal, unused account, unused secret. Layer 4 is lifecycle: rotation cadence, rotation evidence capture, secret leak detection across source code and build logs, deprovisioning workflow when the consuming service is retired, attestation at creation, periodic access review. Layer 5 is detection and response: detect anomalous NHI use (sudden privilege escalation, unexpected geography, unexpected runtime environment, unexpected API call pattern), revoke compromised NHI credentials, rotate downstream secrets, freeze grants, and feed identity-side incidents into the wider incident response programme. A mature programme runs all five with each owning its layer and feeding the others.

What are the recurring NHI adoption pitfalls?

Seven failure modes appear in nearly every NHI programme that stalls. The first is treating secret rotation as the entire programme: rotation matters but does not solve over-privilege, ownership decay, or grant sprawl. The second is rotating on leak instead of on cadence: programmes that only rotate after a leak detection or post-incident never reduce the standing population of long-lived credentials. The third is ignoring SaaS OAuth grants and the federated workload identity surface: programmes focus on cloud IAM and forget that an OAuth grant on a critical SaaS platform or a workload identity federation with a weak trust condition can be more damaging than an over-privileged cloud role. The fourth is no ownership of record: an NHI exists for years with no named human accountable for review; when the original engineer leaves, the NHI becomes orphaned and unreviewed. The fifth is privilege creep through grant accumulation: every project adds a permission, no project removes one, and over years every NHI ends with the union of every project it has ever touched. The sixth is treating NHI findings as a parallel record outside the wider vulnerability programme: an NHI finding lives in a secrets-management dashboard, the vulnerability backlog lives elsewhere, the engagement record lives elsewhere again, and the audit cannot reconstruct the operating posture from one place. The seventh is letting CI/CD identity hygiene drift behind cloud IAM hygiene: programmes harden cloud IAM but tolerate long-lived GitHub tokens, broad GitHub App installation scopes, and CI runners with credentials baked in. Programmes that name and review each failure mode against their estate move from secret-rotation-on-leak to a defensible NHI posture.

What audit and regulatory artefacts does an NHI programme need to produce?

A defensible NHI operating record produces eight artefacts. The NHI inventory itself, dated, with classification fields populated and the source of each entry traced. The NHI policy document with the rules for over-privilege, rotation cadence, lifecycle, ownership, and review. The per-NHI governance record (last reviewed date, named human owner, rotation evidence, exception status if any, criticality classification, lifecycle stage). The exception register for accepted-risk NHIs (long-lived service accounts that cannot be rotated, federated trusts that cannot be tightened, OAuth grants that cannot be scoped down) with named approver and review date. The detection content catalogue and per-incident response record for NHI-side incidents. The leadership read of the NHI posture (population size, percentage with named owner, percentage rotated within policy, percentage with active review, exception count by criticality, incident count by category). The activity log of NHI lifecycle events (creation, attestation, review, rotation, exception, deprovisioning). The framework mapping artefact showing how NHI controls satisfy ISO 27001:2022 A.5.16 and A.5.17 and A.5.18 and A.8.5, SOC 2 CC6.1 and CC6.2 and CC6.3 and CC6.6 and CC7.1, NIST 800-53 Rev. 5 IA-2 and IA-5 and IA-9 and AC-2 and AC-6 and AU-2, PCI DSS v4.0 7.x and 8.6 and 10.x, NIST CSF 2.0 PR.AA-01 and PR.AA-04 and PR.AA-05 and DE.CM-08, CISA Secure by Design goals on eliminating long-lived shared credentials, EU Cyber Resilience Act Article 13, and DORA Articles 9 and 11. Auditors and customer security teams expect each artefact to regenerate from the operating record rather than from a manually maintained spreadsheet.

Does SecPortal function as an NHI security platform?

SecPortal does not market itself as a dedicated Non-Human Identity security platform with native cloud IAM connectors that enumerate every AWS IAM role and Azure managed identity and Google Cloud service account, live secret manager ingestion across HashiCorp Vault and AWS Secrets Manager and Azure Key Vault and Google Secret Manager, federated workload identity discovery across SPIFFE/SPIRE and Workload Identity Federation, real-time OAuth grant telemetry across the SaaS estate, or built-in secret leakage scanning across source repositories. SecPortal does provide the consolidated operating record an internal security, AppSec, product security, cloud security, identity engineering, vulnerability management, or GRC team uses to track NHI findings (imported from a dedicated NHI platform, a CIEM tool, a secrets manager review, a cloud IAM audit, a code scan that surfaces leaked secrets, an authenticated DAST scan that surfaces over-privileged service accounts, a third-party identity audit, or a manual NHI review) under a unified schema with CVSS 3.1 calibration and lifecycle tracking; encrypted credential storage with AES-256-GCM as the scanner credential vault used to authenticate against the workspace owns scanning targets (a verified capability scoped to scanner credentials, not a general NHI vault); bulk finding import for CSV exports of NHI findings from any source; document management for the NHI inventory, NHI policy, per-NHI governance records, exception register, and review evidence; activity log with CSV export for audit-read durability of NHI lifecycle events; compliance tracking against ISO 27001, SOC 2, PCI DSS, NIST, and additional frameworks including the identity-specific controls; team management with RBAC; MFA enforcement; AI report generation for the leadership read of the NHI posture; and code scanning via Semgrep with repository connections via GitHub, GitLab, and Bitbucket OAuth for the code-side leg of the NHI surface (where NHI findings surface inside the codebase, such as embedded secrets and hard-coded credentials). Programmes evaluating dedicated NHI platforms should benchmark coverage of their NHI portfolio (cloud IAM, secret managers, SaaS OAuth grants, CI/CD platforms, service meshes, container orchestrators, federated workload identity) against the named NHI vendors, then use SecPortal as the consolidated operating record that holds the resulting findings alongside the wider security backlog.

← Back to Blog

Technical17 May 202620 min read

Non-Human Identity (NHI) Security: A Practical Guide

Non-Human Identity (NHI) security is the operating discipline of inventorying, classifying, governing, rotating, and detecting attacks against every authenticated principal in the enterprise that is not a human user: service accounts, cloud IAM roles, OAuth client credentials, federated workload identities, CI/CD platform identities, Kubernetes service accounts, database connection accounts, monitoring and scanner agent identities, API keys, personal access tokens used by automation, signing keys, and mTLS certificates between services. In most cloud-anchored enterprises the NHI population now exceeds the human identity population by an order of magnitude, and the published breach reporting from the last several years repeatedly traces high-impact incidents back to compromised non-human credentials. For CISOs, AppSec engineers, product security teams, cloud security teams, identity security teams, vulnerability management teams, GRC and compliance owners, and the security leaders who sponsor the programme, NHI security is the category that names the non-human-identity-attack problem alongside ITDR, ASPM, CSPM, DSPM, SSPM, and AI-SPM. This guide covers what an NHI is and is not, why the NHI population now dominates the identity surface, the five operating layers of an NHI programme, how NHI security differs from IAM, PAM, CIEM, ISPM, and ITDR, the signals an NHI inventory consumes, the recurring adoption pitfalls, the audit-read shape of the operating record against ISO 27001, SOC 2, PCI DSS, NIST 800-53, NIST CSF 2.0, CISA Secure by Design, the EU Cyber Resilience Act, and DORA, and a phased rollout that takes a programme from secret-rotation-on-leak to a defensible NHI posture and detection capability.

What an NHI Actually Is

A non-human identity is any authenticated principal that is not a human user. The category is older than the label. Service accounts have existed since the earliest directory services; cloud IAM roles have existed since the first IaaS offerings; OAuth client credentials have existed since OAuth 2.0; mTLS certificates have existed since the earliest service-to-service architectures. The label is recent because the population has reached a scale where it can no longer be treated as a secondary concern under the human identity programme, and because the recurring high-impact incidents over the last several years have made the security implications visible at the board level.

The breadth of the category matters. NHI is not only cloud IAM roles and not only secrets in a vault. It is the full population of authenticated principals that the enterprise uses to run software, move data, deploy artefacts, query databases, call SaaS APIs, federate workload trust, and rotate the credentials of everything above. The inventory includes service accounts in on-prem directories (Active Directory, LDAP), cloud IAM roles and policies (AWS IAM users and roles, Azure service principals and managed identities, Google Cloud service accounts, Workload Identity Federation principals across cloud boundaries, OCI principals), OAuth client credentials and integration grants on SaaS platforms, federated workload identities (SPIFFE/SPIRE service IDs, Kubernetes service accounts bound to cloud IAM via OIDC, Workload Identity Federation trusts), CI/CD platform identities (GitHub Actions OIDC tokens, GitHub Apps and personal access tokens, GitLab CI job tokens, CircleCI contexts, Jenkins credentials, Azure DevOps service principals), container and orchestrator identities (Pod identities, sidecar service identities, init container identities), service mesh identities (Istio SPIFFE IDs, Linkerd identities, Consul service identities), database connection accounts, monitoring and scanner agent identities, API keys, personal access tokens used by automation, signing keys (artefact signing, image signing, code signing, JWT signing), mTLS certificates used between services, and the short-lived credentials all of the above mint at runtime.

The label “non-human identity” emerged in industry discourse in roughly 2022 to 2023 and accelerated through 2024 to 2025 as the published breach reporting on credential-theft incidents kept naming non-human credentials as the entry point. The category name is now the default term enterprise buyers, identity engineering leads, and CISOs use when describing the non-human-identity-attack problem alongside the human-identity-attack problem ITDR addresses and the cloud-IAM-entitlement problem CIEM addresses.

Why NHI Security Now

Three converging forces have moved NHI from niche identity-engineering concern to CISO-level posture requirement.

Force 1: Population asymmetry

The NHI population has grown faster than the human identity population for over a decade and the gap continues to widen. Every microservice mints at least one identity. Every CI/CD pipeline mints at least one. Every SaaS-to-SaaS integration mints at least one. Every container that runs in production mints at least one. Every automation script, every monitoring agent, every scanner, every database client, every signed-artefact workflow, every webhook receiver, every event-bridge consumer runs as an NHI. The asymmetry in mainstream cloud-anchored enterprises now sits at roughly 45-to-1 to 100-to-1 NHI-to-human and continues to widen as platform teams ship more infrastructure-as-code and as AppSec teams ship more pipelines. The human identity programme cannot scale to cover the NHI population by extension; the NHI population needs its own inventory, classification, governance, lifecycle, and detection layers.

Force 2: Breach reporting

The published incident reports from the last several years repeatedly trace high-impact enterprise breaches back to compromised non-human credentials. Leaked GitHub tokens that grant broad source-control scope; over-permissioned cloud IAM roles assumed by attackers who pivoted from an initial compromise; OAuth integration grants abused after a SaaS-vendor compromise propagated downstream into customer tenants; long-lived API keys exfiltrated from CI logs and reused weeks later; service principal secrets reused across staging and production; signing keys exfiltrated from build environments and used to sign attacker artefacts. The pattern is consistent enough that the question is no longer whether non-human credentials are an attack surface but whether the programme has visibility into its own NHI population.

Force 3: Framework and regulatory pressure

Frameworks have caught up to the operational reality. NIST SP 800-53 Rev. 5 IA-9 names device and non-person entity authentication explicitly. NIST CSF 2.0 PR.AA-04 covers identities and credentials for authorised devices, users, and services. ISO 27001:2022 A.5.16, A.5.17, A.5.18, and A.8.5 cover identity management, authentication information, access rights, and secure authentication for the full identity population. PCI DSS v4.0 8.6 calls out application and system accounts. NIST CSF 2.0 DE.CM-08 covers vulnerabilities in personnel, technology, and data with explicit identity-side reach. The EU Cyber Resilience Act Article 13 requires secure default configuration including authentication and credential management for non-human identities embedded in products. DORA Articles 9 and 11 cover ICT system identity and authentication controls across the EU financial services estate. CISA Secure by Design names the goal of eliminating long-lived shared credentials. Auditors and customer security teams now ask the NHI question explicitly rather than treating it as an identity-engineering implementation detail.

The Five Operating Layers

A working NHI security record exposes five layers. Each can be present or absent in a given vendor offering; programmes evaluating platforms should benchmark each layer separately rather than treating NHI security as a single capability.

Layer 1: Discover the NHI surface

Enumerate every NHI across the estate. Sources include the on-prem directory (Active Directory service accounts, LDAP service accounts), every cloud IAM tenant (AWS IAM users and roles, Azure service principals and managed identities, Google Cloud service accounts, OCI principals, Workload Identity Federation principals across cloud boundaries), every secret store (HashiCorp Vault, AWS Secrets Manager, Azure Key Vault, Google Secret Manager, CyberArk Conjur, Akeyless, 1Password Connect), every CI/CD platform (GitHub Actions OIDC tokens, GitHub Apps and PATs, GitLab CI job tokens, CircleCI contexts, Jenkins credentials, Azure DevOps service principals), every SaaS admin console for OAuth grants and integration registries (Microsoft 365 enterprise apps, Salesforce connected apps, Slack apps, GitHub OAuth Apps, Atlassian apps, Workday integrations), every service mesh control plane (Istio SPIFFE IDs, Linkerd identities, Consul service identities), every Kubernetes API server (Pod identities, service accounts, sidecar identities), every database (connection accounts, replication accounts), every monitoring and scanner agent registration surface. The discover layer is judged by the breadth of source coverage, the ability to surface long-lived secrets across the full estate (which routinely number in the tens of thousands to hundreds of thousands in real enterprise estates), the speed at which a newly minted NHI appears on the record, and resilience against the long tail of acquired-company tenants and shadow SaaS integrations.

Layer 2: Classify each NHI

Tag each NHI against a standing classification scheme. Standard axes include criticality (read-only versus mutation, low-data-scope versus high-data-scope, low-trust-boundary versus cross-trust-boundary, low-blast-radius versus high-blast-radius), lifecycle (long-lived versus short-lived versus ephemeral workload identity), ownership (the named human accountable for periodic review and rotation, distinct from the engineer who originally created it), relationship (the service it serves, the environment, the build, the artefact, the deployment), and regulatory scope (PCI in scope, HIPAA in scope, GDPR personal-data scope, DORA ICT scope, EU CRA product scope). The classification layer is judged by how much of the population can be classified automatically from runtime context versus how much requires manual tagging, the durability of the classification across service changes (an NHI tagged to a service should re-bind when the service migrates rather than orphaning), and the ability of the classification to drive policy enforcement rather than sit as inert metadata.

Layer 3: Govern against a policy

Anchor each NHI against a standing NHI policy. Standard policy fields include the over-privileged grant rule (NHI holds a permission no recent operation used), the missing rotation evidence rule (rotation cadence defined but no rotation event inside the window), the long-lived secret without rotation cadence rule, the no-human-owner-of-record rule, the no-periodic-review rule, the OAuth grant with excess scope rule, the federated workload identity with weak trust condition rule (issuer not pinned, audience claim too broad, subject claim wildcarded), the signing key with no expiry rule, the mTLS certificate with no renewal rule, the unused account rule (no authentication in N days), the unused secret rule (no read in N days), the shared credential rule (the same secret authenticates multiple distinct services), the embedded-in-source-code rule, the embedded-in-build-log rule, and the embedded-in-container-image-layer rule. The governance layer is judged by the precision of the policy rules, the breadth of NHI surfaces the rules cover, the depth of exception handling (an exception requires an approver, a review date, and an inheritance rule when the underlying NHI changes), and the durability of the policy across framework updates and estate changes.

Layer 4: Manage the NHI lifecycle

Run the full lifecycle from creation to deprovisioning. Creation: require attestation (who, why, which service, which environment, what scope, what owner, what rotation cadence). Rotation: enforce cadence with rotation evidence capture; the activity log should be able to answer the question “when did this NHI last rotate and what triggered the rotation” without scraping logs by hand. Leak detection: scan source repositories, build logs, container image layers, and configuration files for committed or exfiltrated secrets; when a leak is detected, the response requires rotation, downstream invalidation, and an incident record. Ownership review: every NHI must have a periodic review where the named owner attests the NHI is still required, the scope is still appropriate, and the rotation evidence is current. Deprovisioning: when the consuming service is retired, the NHI deprovisioning workflow must complete before the service record closes; orphaned NHIs left behind become the highest-risk population. The lifecycle layer is judged by the durability of the rotation evidence (regenerable from the operating record, not assembled by hand), the breadth of leak-detection coverage (source code, build logs, container layers, configuration, chat transcripts, ticket attachments), and the integrity of the deprovisioning workflow.

Layer 5: Detect and respond to NHI attacks

Detect anomalous NHI use: sudden privilege escalation, sudden expansion in API call surface, unexpected geography, unexpected runtime environment, unexpected client identifier, unexpected user agent, unexpected access pattern across previously untouched resources, sudden burst of secret reads after a long idle period, OAuth token reuse from a new device or new IP range, federation trust assumption from an unexpected source. Respond with structured containment: revoke compromised NHI credentials, rotate downstream secrets, freeze grants, suspend federated workload identity trust, expire OAuth grants, freeze signing keys, expire mTLS certificates, and feed the incident into the wider IR programme so the post-incident review covers identity-side lessons alongside endpoint and network ones. This layer overlaps with ITDR content on the attack-detection-and-response side, but NHI security extends ITDR by anchoring detection content specifically on the non-human identity surface (which ITDR offerings often under-cover relative to the human identity surface).

NHI vs IAM, PAM, CIEM, ISPM, ITDR, SCA

NHI security overlaps with several adjacent disciplines. Programmes that conflate them end up with parallel records that no single operator can reconcile.

NHI vs IAM

IAM is the prevention layer for both human and non-human identities: it provisions, authenticates, federates, and enforces baseline access policy. IAM owns the canonical inventory of identities the directory or cloud IAM tenant knows about. NHI security extends IAM by anchoring on the non-human slice specifically, by extending the inventory to surfaces IAM does not control (secret managers, CI/CD platforms, SaaS OAuth grants, federated workload identity), by adding classification and lifecycle layers IAM does not own, and by running detection content that anchors on the non-human attack surface. IAM and NHI security are not substitutes. IAM provisions; NHI security runs the operating record on the non-human slice.

NHI vs PAM

PAM is the elevation-and-control layer focused historically on privileged human accounts: it vaults credentials, brokers sessions, records elevated activity, and enforces just-in-time elevation. Modern PAM products extend into the non-human surface (vault-managed service accounts, secret rotation orchestration, workload secret management). NHI security overlaps with PAM on the vaulting and rotation slice but extends to the full non-human inventory PAM does not control (cloud IAM roles outside the vault, OAuth grants on SaaS platforms, federated workload identity, CI/CD platform identities, signing keys, mTLS certificates). PAM is a strong tool to use inside an NHI programme; it is not the whole programme.

NHI vs CIEM

CIEM (Cloud Infrastructure Entitlement Management) is the cloud-scoped entitlement analysis layer that maps which identities can do what across cloud IAM policies, trust relationships, and resource policies. CIEM analyses both human and non-human identities. NHI security overlaps with CIEM on the cloud IAM slice and depends on a CIEM-grade entitlement model for that surface, but extends to non-cloud-IAM surfaces CIEM does not cover (secret managers, CI/CD platforms, SaaS OAuth grants, federated workload identity outside cloud IAM, mTLS certificate inventory, signing key inventory). A mature NHI programme inherits CIEM output for the cloud IAM slice and owns the remainder of the surface directly.

NHI vs ISPM

ISPM (Identity Security Posture Management) is the broader posture-management layer for the identity provider stack (configuration of the identity provider, authentication policies, conditional access rules, federation trust review, user account hygiene). ISPM covers both human and non-human identities to the extent the identity provider tracks them. NHI security extends ISPM by anchoring specifically on the non-human slice, by extending inventory to surfaces the identity provider does not manage, and by adding lifecycle and rotation evidence ISPM does not own. ISPM is the posture-management peer; NHI security is the operating discipline.

NHI vs ITDR

ITDR is the detection-and-response layer for identity-targeted attacks across the human and non-human surface. NHI security overlaps with ITDR on Layer 5 (detect and respond to NHI attacks) and depends on ITDR-grade detection content for that surface. ITDR offerings historically over-index on the human surface (kerberoasting, golden ticket, MFA bombing) and under-cover the non-human surface (long-lived token reuse from unexpected geographies, OAuth grant abuse, federation trust assumption from new sources). A mature programme runs ITDR and NHI security as adjacent disciplines that share detection content, with NHI security owning the non-human inventory and governance ITDR does not run on its own.

NHI vs SCA and SBOM

Software Composition Analysis (SCA) and Software Bill of Materials (SBOM) work address the component lineage of the software the team ships. NHI security addresses the identity lineage of the same pipeline: which identity authenticated the build, signed the artefact, pushed the container image, invoked the deploy, reads the runtime secrets. A compromised CI/CD identity can publish a clean SBOM against a tampered artefact, and a leaked deploy key can ship a vulnerable component the SBOM and VEX records say was sandboxed. The two disciplines reinforce each other rather than compete; programmes run both inside the wider software supply chain security operating record.

Signals the NHI Inventory Consumes

An NHI inventory consumes signals across the full estate. The inventory is only as durable as the breadth of sources feeding it and the freshness of the data behind each source.

Cloud IAM enumeration: AWS IAM users, roles, policies, trust relationships, AWS Organizations service control policies, Azure service principals, managed identities, role assignments, custom roles, Google Cloud service accounts, IAM bindings, Workload Identity Federation pool members, OCI principals.
Secret store enumeration: HashiCorp Vault leases and policies, AWS Secrets Manager secrets and rotation schedules, Azure Key Vault secrets, keys, and certificates, Google Secret Manager secrets and versions, CyberArk Conjur identities, Akeyless items, third-party secret manager records.
CI/CD identity surfaces: GitHub Actions OIDC token usage, GitHub App installations, GitHub PATs and fine-grained PATs, GitLab CI job tokens and project access tokens, CircleCI contexts and project tokens, Jenkins credentials, Azure DevOps service connections.
SaaS OAuth grant inventory: Microsoft 365 enterprise applications and admin consent grants, Salesforce connected apps, Slack apps, GitHub OAuth Apps, Atlassian apps, Workday integrations, Snowflake network policies and service users, third-party SaaS integration registries.
Federated workload identity: SPIFFE/SPIRE service identities, Kubernetes service accounts bound to cloud IAM via OIDC, Workload Identity Federation across cloud and SaaS boundaries, service mesh control plane identity registries.
Code-side signals: secret scanning across source repositories, build logs, container image layers, IaC files, configuration files, chat transcripts, and ticket attachments for committed or exfiltrated credentials.
Database and data plane identities: database connection accounts, replication accounts, data warehouse service users, queue consumer identities, event bus subscriber identities, object storage access principals.
Signing key and certificate inventory: artefact signing keys (Sigstore, Cosign, Notary, in-toto), code signing certificates, image signing keys, JWT signing keys, mTLS certificates across services, gateway certificates, internal CA hierarchies.
Activity and audit signals: identity provider events, cloud IAM CloudTrail and Azure Activity Log and Google Cloud Audit Log entries, SaaS audit logs, secret-read events, OAuth grant creation and revocation events, federation trust assumption events, signing key use events, mTLS certificate issuance and renewal events.

Recurring Adoption Pitfalls

Seven failure modes appear in nearly every NHI programme that stalls. Naming them up front lets the programme design the operating record to avoid them.

Pitfall 1: Rotation as the whole programme

Programmes that scope NHI security to secret rotation never solve over-privilege, ownership decay, or grant sprawl. Rotation is necessary but not sufficient. A rotated credential with broad scope and no owner is still a risk; a rotated OAuth grant that still holds excess scope is still a risk; a rotated long-lived token that no recent operation uses is still a risk. NHI security requires the full five-layer record, not the rotation slice in isolation.

Pitfall 2: Rotate on leak, not on cadence

Programmes that only rotate after a leak detection or post-incident never reduce the standing population of long-lived credentials. The standing population is the attack surface; the leak detection is the cleanup. A standing population of ten-thousand long-lived secrets without rotation evidence is a CISO-level risk regardless of how strong the leak detection is. NHI policy must define a rotation cadence per classification and enforce it through evidence capture, not through reactive cleanup.

Pitfall 3: Ignore SaaS OAuth grants and federated workload identity

Programmes that focus on cloud IAM and forget the SaaS OAuth grant surface or the federated workload identity surface miss two of the highest-impact attack surfaces. A compromised OAuth grant on a critical SaaS platform can be more damaging than an over-privileged cloud IAM role because the SaaS data plane has no equivalent of cloud-native logging or detection. A federated workload identity with a weak trust condition (issuer not pinned, audience too broad, subject wildcarded) can be assumed by an attacker who controls the issuer, bypassing the cloud IAM trust model entirely. The NHI inventory must cover both surfaces or it does not cover the attack surface that recent incidents have demonstrated.

Pitfall 4: No human owner of record

An NHI exists for years with no named human accountable for periodic review. When the engineer who created it leaves the company, the NHI becomes orphaned and unreviewed. The orphaned population grows quietly. The programme that does not enforce a named human owner at creation and does not re-bind the owner when the original owner departs eventually carries an NHI population where a meaningful fraction has no responsible operator. The audit-read shape of this is a single number: the percentage of the NHI population with a named owner of record. Programmes that cannot answer the number cannot answer the question “who is responsible for the over-permissioned service account that was just used in the breach”.

Pitfall 5: Privilege creep through grant accumulation

Every project adds a permission, no project removes one. Over years every NHI ends with the union of every project it has ever touched. The policy rule “NHI holds a permission no recent operation used” is the entry point. Mature programmes pair the rule with a quarterly review where the named owner attests which permissions the NHI still requires; the unused permissions are removed; the rotation cadence resets. The discipline is manual but the operating record can carry it cheaply once the review cadence is in place.

Pitfall 6: NHI findings parallel to the rest of the backlog

An NHI finding lives in a secrets-management dashboard, the vulnerability backlog lives elsewhere, the engagement record lives elsewhere again. The audit cannot reconstruct the operating posture from one place; the leadership read of “what is the state of our identity programme” returns three numbers from three systems. Mature programmes consolidate the NHI findings into the wider vulnerability backlog under the same severity scheme, the same ownership routing, the same SLA policy, and the same evidence shape, so the leadership read regenerates from one operating record.

Pitfall 7: CI/CD identity hygiene lags cloud IAM hygiene

Programmes harden cloud IAM but tolerate long-lived GitHub tokens, broad GitHub App installation scopes, and CI runners with credentials baked into the runner image. The CI/CD surface is now where most production deploys originate and where most signed artefacts come from; an attacker who compromises a CI/CD identity can ship arbitrary code into production with the organisation's own signature on it. The NHI programme must cover the CI/CD surface with the same rigour as cloud IAM: short-lived OIDC tokens preferred over long-lived PATs, GitHub Apps with least-privilege installation scopes, fine-grained PATs where PATs are required, runner identity attestation, and deploy-key inventory.

Audit-Read Shape of the NHI Operating Record

A defensible NHI operating record produces eight artefacts that regenerate from the live record rather than from a separate evidence pack.

The NHI inventory itself. Dated, with classification fields populated and the source of each entry traced back to the cloud IAM tenant, secret store, CI/CD platform, SaaS OAuth registry, or other source.
The NHI policy document. Rules for over-privilege, rotation cadence per classification, lifecycle (creation, attestation, review, deprovisioning), ownership, and exception handling.
The per-NHI governance record. Last reviewed date, named human owner, rotation evidence, exception status if any, criticality classification, lifecycle stage, and the link to the consuming service.
The exception register. Accepted-risk NHIs (long-lived service accounts that cannot be rotated, federated trusts that cannot be tightened, OAuth grants that cannot be scoped down) with named approver, decision class, and review date.
The detection content catalogue and per-incident response record. NHI-side detection content (anomalous use, unexpected geography, token reuse, OAuth abuse, federation assumption from new source) with the per-incident response record (who responded, what was revoked, what was rotated, what downstream invalidation ran).
The leadership read. Population size, percentage with named owner, percentage rotated within policy, percentage with active review, exception count by criticality, incident count by category, and trend across reporting periods.
The activity log. Creation, attestation, review, rotation, exception, and deprovisioning events with the acting operator captured for audit-read durability.
The framework mapping artefact. Showing how NHI controls satisfy ISO 27001:2022 A.5.16, A.5.17, A.5.18, and A.8.5; SOC 2 CC6.1, CC6.2, CC6.3, CC6.6, and CC7.1; NIST SP 800-53 Rev. 5 IA-2, IA-5, IA-9, AC-2, AC-6, and AU-2; PCI DSS v4.0 7.x, 8.6, and 10.x; NIST CSF 2.0 PR.AA-01, PR.AA-04, PR.AA-05, and DE.CM-08; CISA Secure by Design goals on eliminating long-lived shared credentials; EU Cyber Resilience Act Article 13; and DORA Articles 9 and 11.

Phased Rollout

A practical NHI rollout runs in three phases over roughly a quarter, then transitions to recurring cadence.

Phase 1 (weeks 1 to 4): Anchor the inventory and classification

Enumerate the cloud IAM, secret store, CI/CD platform, and SaaS OAuth grant surfaces. Tag each NHI with owner, criticality, lifecycle, and consuming service. Identify the unowned and the long-lived populations. Land the inventory and the first governance pass against the standing policy. Triage the highest criticality unowned NHIs first.

Phase 2 (weeks 5 to 8): Wire lifecycle and rotation evidence

Define rotation cadence per classification and start capturing rotation evidence in the activity log. Wire leak detection across source repositories and build logs. Run the deprovisioning workflow on the easy-win subset (retired services with surviving NHIs). Land the exception register for the NHIs that cannot rotate or cannot tighten scope. Extend the leadership read with the rotation percentage and exception count.

Phase 3 (weeks 9 to 12): Extend detection and audit-read durability

Wire NHI-side detection content (anomalous use, unexpected geography, OAuth abuse, federation assumption from new source). Land the per-incident response playbook (revoke, rotate, freeze grants, expire OAuth, expire mTLS, expire signing keys). Run the first quarterly review across the named owners. Refresh the framework mapping artefact and land the multi-framework crosswalk so the audit-read regenerates from the operating record.

Recurring cadence (weekly, monthly, quarterly, annually)

Weekly: triage new findings from leak detection, anomalous use, and the policy engine; close finished rotations and deprovisionings; refresh the unowned and exception views. Monthly: review the leadership read with the security programme owner; refresh exception decisions whose review dates have passed. Quarterly: run the named-owner attestation cycle across the population; refresh classification on services that have changed. Annually: re-baseline the policy against the latest framework versions (ISO 27001 control updates, NIST CSF revisions, PCI DSS revisions, EU CRA enforcement updates, DORA RTS updates).

Where SecPortal Sits in an NHI Programme

SecPortal does not market itself as a dedicated NHI security platform with native cloud IAM connectors, live secret manager ingestion, federated workload identity discovery, real-time OAuth grant telemetry, or built-in secret leakage scanning across the full enterprise estate. The platform is the consolidated operating record where NHI findings, NHI policy artefacts, NHI governance records, exception decisions, and audit-read evidence land alongside the wider security backlog.

The verified product surface that supports NHI work is the following. Findings management holds NHI findings from any source under a unified schema with CVSS 3.1 calibration and full lifecycle tracking. Bulk finding import ingests CSV exports of NHI findings from a CIEM tool, a secret manager review, a cloud IAM audit, a code-side secret scanner, an authenticated DAST scan that surfaces over-privileged service accounts, a third-party identity audit, or a manual NHI review. Encrypted credential storage uses AES-256-GCM with per-record IVs and authentication tags for the workspace own scanner credential vault that authenticates the authenticated DAST against the workspace own scanning targets (this is the scanner credential vault, not a general enterprise NHI vault). Code scanning via Semgrep with repository connections via GitHub, GitLab, and Bitbucket OAuth surfaces the code-side leg of the NHI surface where embedded secrets, hard-coded credentials, and weak authentication patterns live inside the codebase. Document management holds the NHI inventory, NHI policy document, per-NHI governance records, exception register, named-owner attestation evidence, and framework mapping artefact. Activity log with CSV export captures NHI lifecycle events (creation, attestation, review, rotation, exception, deprovisioning) with the acting operator for audit-read durability. Compliance tracking maps NHI controls against ISO 27001, SOC 2, PCI DSS, NIST, and additional frameworks. AI report generation via Claude produces the leadership read of the NHI posture. Team management with RBAC and MFA enforcement cover the operator-side controls on the platform itself.

Programmes that already run a dedicated NHI security platform or a CIEM tool with NHI coverage should plan SecPortal as the operating record that holds the resulting findings, the leadership read, the exception register, and the framework mapping. Programmes that do not yet run a dedicated NHI tool should start by running the inventory and classification on whatever signals they can pull today (cloud IAM exports, secret manager exports, CI/CD platform audits, manual SaaS OAuth grant reviews), land the operating record on the platform, and then evaluate dedicated NHI tools against the population the operating record now makes visible.

Who Reads the NHI Operating Record

CISOs and security leaders read the leadership numbers (population size, percentage with named owner, percentage rotated within policy, exception count by criticality, incident count by category) and report identity-side risk to the board against the same operating record the programme runs against.
AppSec teams own the code-side leg of the NHI surface (embedded secrets, hard-coded credentials, weak authentication patterns in source code) and triage NHI findings inside the wider AppSec backlog.
Product security teams cover the NHI surface of the product the company ships, especially the long-lived embedded credentials, signing keys, and authentication patterns that influence EU CRA Article 13 compliance.
Cloud security teams own the cloud IAM, secret manager, and federated workload identity surface and run the day-to-day NHI inventory and rotation work for the cloud-anchored estate.
Vulnerability management teams triage NHI findings inside the wider vulnerability backlog under the same severity scheme, ownership routing, SLA policy, and evidence shape as the rest of the programme.
GRC and compliance teams regenerate the audit-read artefacts (inventory, policy, exception register, framework mapping) from the operating record at audit time rather than assembling them by hand.
Security engineering teams wire the discovery connectors, the policy engine, the detection content, and the lifecycle automation that make the NHI programme run at scale.
Security operations leaders run the per-incident response when NHI-side detection content surfaces an anomalous use signal and own the rotation, revocation, and downstream invalidation across the response.
Internal security teams of all sizes are the day-to-day operators who land the inventory, run the classification, enforce the policy, and review the backlog every week.

Scope and Limitations

This guide describes the operating shape of Non-Human Identity security as it is consumed in mainstream enterprise programmes. The vendor landscape evolves rapidly: cloud IAM connector coverage, secret manager ingestion breadth, federated workload identity discovery, SaaS OAuth grant telemetry depth, NHI-specific detection content, behavioural analytics on non-human activity, and bundled posture-management capabilities shift between releases. Specific feature claims, supported providers, and the precision of named detection content should be verified against current vendor documentation and against benchmark exercises on the team own NHI portfolio.

NHI security is an operating discipline that runs on top of IAM, PAM, CIEM, ISPM, ITDR, and the wider GRC programme; it is not a substitute for any of them. Programmes that adopt NHI security as a substitute for the identity provider lose the authoritative authentication layer; programmes that adopt NHI security as a substitute for PAM lose the privileged-session control layer; programmes that adopt NHI security as a substitute for the wider GRC programme lose the cross-framework crosswalk discipline. Programmes that adopt NHI security as the non-human-identity layer alongside IAM, PAM, CIEM, ISPM, ITDR, and the wider GRC posture, with disciplined inventory, classification, governance, lifecycle, and detection-and-response, are the ones that see durable operating value.

Run NHI findings on SecPortal

Stand up the operating record in under two minutes. Free plan available, no credit card required.

Get Started Free SecPortal for internal security teams