Non-human identities (NHIs) — service accounts, API keys, OAuth tokens, CI/CD secrets and integration credentials — now outnumber human users in most mid-size enterprises by ratios of 10:1 or higher. They live longer, rotate less, are owned by no one in particular, and increasingly attract attackers who realise that compromising one well-placed service token can do more damage than phishing a human.
The shift to cloud, SaaS, automation, AI agents and platform engineering has multiplied non-human identities at a pace that traditional IAM programmes were never designed for. Most organisations don't even know how many NHIs they have, who owns them, or what they can actually do.
This article is a practical, opinionated guide: why NHI risk is now critical, what real inventory looks like, how to apply least privilege without breaking operations, how to rotate secrets reliably, what to detect, what to measure and how to roll out a 90-day plan. We close with the common mistakes that turn an NHI programme into shelf-ware.
Why this risk is now critical
In most mid-size enterprises NHIs vastly outnumber human users: service accounts in Active Directory and Entra ID, CI/CD secrets, SaaS-to-SaaS integration tokens, internal API keys and credentials embedded in legacy scripts. The problem isn't just the count — it's that these identities tend to live longer, hold broader permissions, and have weaker change controls than any human account would tolerate.
Attackers know this. Several high-profile breaches in 2024-2026 started with a stolen long-lived token, an exposed CI/CD secret or an API key with way more scope than it needed. The infostealer ecosystem and the post-exploitation toolkits both now ship with specific modules to harvest tokens, refresh OAuth grants and pivot through service accounts. NHI security is no longer a hygiene topic — it's a top-tier attack surface that intersects with cloud identity and Zero Trust posture and with AI agent security, where every autonomous agent is, by definition, a non-human identity.
Real inventory with verifiable ownership
The first high-impact control is to build a living inventory — not a static spreadsheet. For every NHI it must capture: the system where the identity lives, the business process it supports, criticality level, last use, last secret change, scope of permissions, technical owner and business owner. An inventory without verifiable ownership is just decoration: when an incident hits or a credential leaks, there has to be somebody on call who can decide what to do in minutes.
Inventory should be assembled from the systems of record — Entra ID and Active Directory, AWS/Azure/GCP IAM, secret managers, CI/CD platforms, SaaS admin consoles, internal API gateways — and reconciled regularly against what's actually being used. NHIs with no observed activity for 90+ days are either dead and should be removed, or sleeper risks that warrant explicit review and re-justification.
Least privilege without breaking operations
Applying least privilege to service accounts is not about cutting permissions by feel — it's about designing role profiles per task and validating real usage. A practical approach starts with identities of highest blast radius: access to sensitive data, admin privileges, or cross-environment scope. Use telemetry from CloudTrail, Azure Activity Log, Google Cloud Audit Logs or platform-equivalent sources to see what each NHI actually does, then trim what it never uses.
Pair least-privilege enforcement with Microsoft 365 security hardening when M365 service principals are in scope, and integrate the work into the broader vulnerability management programme so that excessive-permission findings are tracked with the same rigour as classic CVEs. The goal is enforceable, auditable, automated — not a one-off cleanup that decays in three months.
Secret rotation and lifecycle
Manual rotation is fragile and almost always late. The operational standard should be automated rotation with windows defined by criticality: more frequent for high-impact identities and longer for low-risk integrations, always with a hard maximum. Every secret should have an explicit lifecycle: who created it, what it's for, when it was last rotated, when it will rotate next, and what the revocation path looks like if it's compromised.
Modern secret managers (HashiCorp Vault, AWS Secrets Manager, Azure Key Vault, Google Secret Manager, Doppler, 1Password Service Accounts) make rotation tractable when paired with a workload identity model. Where automation isn't possible yet, document the manual rotation procedure, test it quarterly, and treat any secret older than its maximum age as a finding.
Early abuse detection
Protecting the secret isn't enough — you have to detect anomalous use. Define a baseline per identity: working hours, destination services, typical call volume, source location and action patterns. Any meaningful deviation should generate an alert enriched with business context, not a raw log event nobody reads. Without that baseline, an attacker using a stolen token looks identical to a legitimate automated job.
This is exactly where a managed SOC earns its keep, supported by proactive threat hunting to find compromised tokens before they trigger an incident, and a fast-path incident response when something does go wrong. The combination of identity telemetry, behavioural baselines and 24/7 monitoring is what turns NHI security from a posture exercise into an operational defence.
Metrics that actually show maturity
To measure real progress, avoid vanity metrics. Prioritise actionable indicators: percentage of identities with an assigned owner and current review, ratio of secrets rotated within SLA, number of orphan identities removed per period, mean time to revoke during incidents, and coverage of behavioural baselines. These numbers tell you whether the programme is improving or quietly decaying.
Board-level reporting should focus on a small set: ownership coverage, rotation compliance, blast-radius reduction and detection capability. Resist the temptation to report the total NHI count as a metric — it will only ever grow, and growing isn't bad. What matters is whether each NHI is governed and observable.
A 90-day implementation plan
Days 1-30: minimum viable inventory and criticality classification. Don't try to be exhaustive — focus on the systems where NHI compromise would hurt most (M365/Entra ID, cloud accounts, CI/CD, customer-facing APIs). Assign technical and business owners for every identity in scope. Stand up a tracking system, even if it starts as a shared dashboard.
Days 31-60: remediation of excessive privileges on the top-20 highest-impact identities. Activate automated rotation on key integrations. Document the revocation runbook and test it. Days 61-90: deploy anomaly monitoring, run tabletop exercises for stolen-token scenarios, and integrate findings into the regular risk reporting cycle. By day 90 you should have a defensible posture on critical NHIs and a documented roadmap for the long tail.
Common mistakes to avoid
A frequent mistake is mixing identities for different services under the same credential out of operational convenience. Another is allowing permanent exceptions with no expiry date or formal review. A third is trusting that "nobody knows that key" and skipping usage telemetry — when in reality, an attacker who lands on the credential is often the one who observes the lack of monitoring and acts confidently because of it.
Also common: confusing NHI security with secret-manager deployment. A secret vault is a necessary tool, but it doesn't replace ownership, least-privilege design, rotation policy or detection. Organisations that buy a vault and call it done usually find out a year later that secrets are still being pasted into Slack and committed to private repositories, because nobody changed the underlying behaviour.
How Hard2bit helps
Hard2bit helps organisations build NHI security as part of a broader identity, cloud and operational programme. The work typically combines a cybersecurity audit that surfaces the actual NHI landscape, a cloud and IAM posture review for prioritisation, integration with managed SOC for detection, and alignment with NIS2, DORA or ISO 27001 compliance objectives when they apply.
If your organisation is moving from spreadsheets to a real NHI programme, talk to a Hard2bit specialist and we'll help you scope the work, prioritise the first 30 days and avoid the most expensive mistakes.
Note: NHI risk has to be assessed in the context of each organisation's stack, regulatory perimeter and operational maturity. This article is informational and does not replace a technical audit, a configuration review or a formal compliance assessment.