NHI · Service accounts · OAuth · API keys · Workload · Vault
Non-human identities security
Tokens, secrets, service accounts, SaaS integrations, API keys and workloads outnumber human users by ratios of 20:1 to 50:1, and very few have an owner, rotation or monitoring. End-to-end NHI governance programme from inventory to safe decommissioning.
Executive summary
Non-human identities (NHI) grow far faster than human ones, rarely have a clear owner, almost never use MFA, their secrets are not rotated and they keep broad permissions "just in case". When an attacker compromises an active NHI with excessive permissions, detection cost is high because it does not produce the anomalous behaviour typical of a compromised human user.
The service covers the full NHI-specific lifecycle: consolidated discovery across cloud, SaaS, on-prem and code; functional owner attribution; secrets governance with automated rotation; real privilege reduction; monitoring and safe decommissioning. Suitable to support ISO 27001:2022 (A.5.16, A.5.17, A.8.2), ENS (op.acc.1, op.acc.4, mp.info.4), NIS2 art. 21.2.i and DORA art. 9.
Growing, silent risk
For every new human user, dozens of NHIs are spun up. Without a dedicated programme, identity debt grows exponentially and silently.
Specific lifecycle, not traditional IAM
NHIs do not join and leave with HR. Typical MFA does not apply. They need automated rotation, workload federation and explicit functional ownership.
Regulatory evidence
ISO 27001:2022, ENS, NIS2 and DORA explicitly cover NHIs. We deliver traceable inventory, owners, rotation, least privilege and monitoring.
What we cover in an NHI programme
Twelve areas that together give real visibility and control over the NHI ecosystem. Not all need to be tackled at once: we prioritise the critical ones based on the diagnostic.
Directory service accounts
Active Directory and Entra ID: identification, attribution, long non-rotatable password policy, service restriction for where they can authenticate, gMSA where applicable.
OAuth tokens to SaaS
Microsoft 365, Google Workspace, Salesforce, Slack, GitHub: inventory of connected apps, periodic scope review, new-app approval policy, automatic disabling of inactive ones.
API keys
Inventory by provider (Stripe, SendGrid, Twilio, AWS, etc.), automated rotation, short-lived token principle where the provider supports it, anomalous-use alerts.
Cloud workload identities
IAM Roles in AWS, Managed Identities in Azure, Service Accounts in GCP, Workload Identity Federation. Replace secrets with federation whenever possible.
Kubernetes service accounts
Cluster ServiceAccounts, appropriate RBAC by namespace, OIDC integration with the cloud provider, avoiding long-lived tokens mounted by default.
Personal access tokens (PAT)
PATs on GitHub/GitLab/Bitbucket/Atlassian: inventory, owner attribution, mandatory expiry policy, replacement with GitHub Apps where viable.
Secrets in code and CI/CD
Scanning of repositories and Git history, secrets in pipelines (GitHub Actions, GitLab CI, Jenkins), environment variables in containers, deployed .env files.
Centralised secrets management
Deployment or reform of Vault/Secrets Manager/Key Vault/CyberArk by stack. Progressive migration of scattered secrets to the centralised manager.
RPA and office automation
Power Automate, UiPath, Zapier, Make: every automated flow uses identities that rarely get inventoried. Govern them with the same criteria as technical ones.
External supplier identities
Tokens and accounts handed to auditors, consultants, MSPs, integrators. Mandatory expiry, internal owner, review at supplier exit.
Monitoring and alerts
Key events: use from a new geography, out of hours, anomalous volume, authentication after inactivity, attempted use after expiry.
Safe decommissioning
Procedure to retire NHIs without breaking critical integrations: mapped dependencies, gradual revocation window, post-decommission verification, documented archive.
Anatomy of a critical finding
Real technical pattern, anonymised: OAuth app connected to Microsoft 365 by a supplier who no longer works with the organisation, with broad permissions over mailboxes and SharePoint, no rotation for over a year, no recognised internal owner.
Discovery
OAuth app with excessive scopes in Microsoft 365
During the inventory of OAuth apps connected to the tenant we detected "AcmeIntegrator SaaS" with Mail.Read, Sites.ReadWrite.All and Files.ReadWrite.All scopes granted at tenant level 18 months earlier. The company that registered the app stopped working with the client 9 months ago. The token is still active. No current employee recognises having approved it.
Real risk
Silent access to mail and SharePoint
With those scopes the app can read any tenant mailbox and modify any SharePoint site. The token does not produce interactive login, does not appear in human sign-in logs, does not require MFA. The Unified Audit Log review showed sporadic accesses in the last few months, all within the legitimate behaviour of the original integration. Distinguishing inherited legitimate use from malicious use is non-trivial.
Evidence
Documented traceability
Capture of the app registration in Entra ID with consent date, scopes and the employee who approved (no longer on staff); Unified Audit Log history filtered by AppId; detected dependencies of processes still consuming the integration; proposed migration plan. All suitable to inform the DPO and the ENS/ISO auditor.
Remediation
Controlled revocation + policy
Immediate: consent revocation, invalidation of active tokens, review of any access in the previous 72 hours. One week: approval policy for new OAuth apps (admin consent workflow), scheduled quarterly review of existing ones, automatic disabling of those inactive for more than 90 days. Monthly: alert monitoring of any new app with elevated scopes.
Anonymised technical case based on real patterns. Sector and names altered; the technical pattern and the remediation procedure stay faithful to the original.
When it fits and when it does not
Fits very well
When it is worth it
- Organisation with multiple main SaaS (M365 + Google + Salesforce + Slack + GitHub + integrations)
- Multi-cloud (AWS + Azure, or any combination with on-prem)
- ISO 27001:2022, ENS Alta, NIS2 or DORA compliance with a strict auditor
- After an incident involving a compromised token or service account
- M&A: inheriting tenants with unknown NHIs
- Development team with multiple SaaS integrations
- IAM modernisation: the natural next step after consolidating human IAM
Fits less well
When it is not the first move
- Small organisation with a single SaaS and a single cloud: start with basic human IAM
- Human IAM not yet consolidated: order it first
- No secrets manager and no budget to deploy one: the project would stay half-done
- After an active unresolved incident: first incident response
How we deliver
Five phases. The first two overlap partially, the next three are sequential. The plan adapts to the diagnostic: in organisations with good human IAM the pace quickens; in those starting from zero the attribution phase needs more support.
1. Discovery (1-3 weeks)
Consolidated inventory: NHIs in cloud (AWS/GCP/Azure IAM), main SaaS (M365, Google Workspace, Salesforce, GitHub, etc.), AD/Entra ID, current secrets manager if any, code repositories. Output: master inventory with type, age, last use, scopes.
2. Attribution and prioritisation (2-3 weeks)
Each NHI to a functional owner with expiry. What cannot find an owner becomes a decommission candidate. Prioritisation by risk: elevated scopes without use, old secrets, accounts without MFA where they should have it, crossed accesses between production and non-production.
3. Secrets governance (2-4 weeks)
Deployment or reform of the secrets manager. Progressive migration of scattered secrets. Automated rotation of the most critical ones. Pre-commit hooks and CI rules to block new secrets in code.
4. Least privilege (2-4 weeks)
Real usage analysis for each NHI with broad permissions. Reduction to real least privilege. Replacement of static keys with workload federation where the cloud supports it. Policy and workflow for new grants.
5. Monitoring and handover
Operational alerts in the client's SIEM/SOAR, NHI programme health dashboard, operational documentation, training for the operations team. If continuous operation is contracted, we take over the cycle; if not, orderly transfer.
What the documentation package includes
1. NHI master inventory
Consolidated table per identity: type, system, owner, last use, last rotation, scopes, criticality and assigned plan.
2. Technical findings report
Each finding with description, risk, evidence, prioritised recommendation and dependencies.
3. Executive report
2-3 pages without jargon for the board. Programme KPIs, top risks and action plan.
4. Remediation roadmap
Plan prioritised by risk + effort: critical immediately, medium in 30-60 days, structural in 90-180 days.
5. Policies and workflows
NHI management policy, OAuth apps policy, approval and decommission workflow, templates for owners.
6. Evidence repository
Signed ZIP with captures, exports from audited systems, proposed configuration and action logs. Suitable for external auditors.
Adaptation by sector
B2B SaaS and software factory
Very high NHI volume due to intensive SaaS integration use and cloud-native architectures. Focus on workload federation (AWS IRSA, GCP Workload Identity, Azure Managed Identities), GitHub Apps instead of PATs, secrets management in CI/CD.
Financial entities
DORA art. 9 covers application identities. Focus on service accounts in payment systems, integrations with critical ICT suppliers (PSP, core banking), traceability of any access to transaction systems.
Healthtech
GDPR art. 9 (special category data). Focus on NHIs with access to clinical records, HL7/FHIR integrations, identities of connected medical devices, segregation between production and test environments.
Public sector and government services
ENS by categorisation (op.acc.1, op.acc.4, mp.info.4). Focus on service accounts on legacy systems, integrations with administrative platforms (SIA, @firma), full traceability for the administrative auditor.
Industry and OT
NHIs at the IT/OT boundary: service accounts that connect industrial systems with the rest of the network, integrations with SCADA/MES platforms, identities of robots and PLCs. Lateral movement risk if poorly governed.
Retail and e-commerce
Focus on payment gateway API keys, marketplace integrations, OAuth to marketing and analytics SaaS, logistics platform service accounts. High seasonal volume.
Regulatory fit
| Framework | Reference | What it requires and how we cover it |
|---|---|---|
| ISO 27001:2022 | A.5.16 / A.5.17 / A.8.2 | Identity management, authentication information and access privileges. Explicitly covers NHIs. |
| ENS | op.acc.1 / op.acc.4 / mp.info.4 | Identification, authentication mechanism and key encryption. Applicable to Medium and High categories. |
| NIS2 | Art. 21.2.i | Multi-factor or continuous authentication and encryption where appropriate. Applies to application identities with critical access. |
| DORA | Art. 9 + RTS on ICT risk management | Access rights management policy, including application identities. Traceability for the financial supervisor. |
| PCI DSS v4.0.1 | Req. 8.6 (non-user accounts) | System and application accounts with robust authentication, no reuse, documented rotation. |
| NIST CSF 2.0 | PR.AA / PR.IR | Identity, authentication and access management as a central category, also for non-human identities. |
| GDPR | Art. 32.1.b/d | Permanent confidentiality and integrity and regular verification of effectiveness. NHIs with access to personal data fall in scope. |
What we tend to do and others do not
Cross inventory cloud + SaaS + on-prem + code
Many services only cover NHIs in cloud, or only in SaaS. Without the unified view, 30-50% of the real problem remains outside scope.
Forced attribution with expiry
Every NHI gets a functional owner with mandatory periodic renewal. What no one claims becomes a decommission candidate. The only way to stop silent growth.
Workload federation instead of keys
Where the cloud allows it (AWS IRSA, GCP Workload Identity Federation, Azure Managed Identities), replace static secrets with federation. Eliminates the problem category.
Blocking pre-commit + CI
We deploy hooks that block new secrets before commit and CI rules that fail the build. Stops the debt from growing while we clean up.
Real usage analysis for least privilege
We do not reduce permissions by intuition. We analyse historical real usage for each privileged NHI before proposing the specific reduction.
Safe decommissioning plan
Procedure to revoke NHIs without breaking integrations: previously mapped dependencies, revocation window, post-decommission verification, documented archive.
Objections we hear and how we answer
«A supplier already manages our IAM»
That almost always means human IAM. NHIs are a distinct discipline with their own controls. We work with your existing IAM supplier, we do not replace them: we add the NHI layer that usually sits outside the standard scope.
«It is a huge project, we cannot fit it in»
We deliver it in phases. Initial 1-2 week diagnostic to understand volume. First phase focused only on critical NHIs (admin tokens, accounts with sensitive data access, OAuth apps with elevated scopes). The rest is planned in later sprints. No need to eat the whole plate.
«Any rotation breaks integrations»
That is why the procedure is always: identify dependencies, scheduled window with owner, rollback plan, verification. We do not rotate blindly. And where the breakage risk is high and the compromise risk is low, we say so honestly and accept the debt with a deadline.
«Will we need more tools?»
Depends on the starting point. If there is already a secrets manager, no. If not, we recommend one appropriate to the stack, without partner bias: native integration with your main cloud, predictable cost, automated rotation for the common providers. If open-source Vault fits, we recommend it without raising a licence.
«Is this only for large organisations?»
No. A mid-sized organisation with M365 + Google Workspace + GitHub + 5 main SaaS already exceeds 200-300 NHIs without knowing it. The programme scales: in a mid-sized organisation it takes 8-12 weeks; in a large one it can reach 6 months due to organisational complexity, not technical.
«Does this reduce development productivity?»
The opposite. Well deployed, the development team stops managing secrets manually: they request them from the manager via API, rotation is transparent and stopping the maintenance of .env files saves work. The initial migration cost pays back in a few months.
How we measure NHI programme health
Six indicators we report in a monthly governance session. They let the steering committee see whether the programme is advancing, stalling or regressing.
% NHIs with assigned owner
Master indicator. Target: >95% in 90 days. Without an owner there is no one to make decisions on the identity.
% NHIs with secret rotated on time
According to defined policy (30/90/180 days by criticality). Target: >90%. Direct indicator of operational health.
% NHIs with least privilege scopes
Identities whose scopes have been reviewed and reduced in the last 12 months. Target: 100% for critical, >80% for the rest.
Average NHI decommission time
Days from detection of an unused NHI to its effective decommission. Target: <30 days for non-critical, <7 days during an incident.
Secrets blocked in code (CI)
Monthly trend of secrets blocked by hooks/CI. Target: sustained downward trend.
Inventory coverage
Percentage of in-scope systems whose NHI inventory is updated in the last quarter. Target: 100% for critical.
Common mistakes in NHI programmes
- Starting with the tool. Buying an NHI solution without prior inventory and attribution guarantees wasted budget.
- Treating NHIs with the same controls as humans. MFA and password expiry do not apply the same: you need automated secrets rotation and workload federation where possible.
- Inventorying only cloud and forgetting SaaS. OAuth apps to M365/Google/Salesforce are where most silent exposure sits.
- Not attributing a functional owner. Without an owner no one decides what to do with a doubtful NHI: either all of them stay or critical integrations break when deleting blindly.
- Rotating blindly without dependency mapping. The first time a critical secret is rotated without knowing what consumes it, production systems break.
- Reducing privileges without usage analysis. Causes immediate breakage or, worse, gets logged and rolled back without documentation.
- Cleaning current code without touching Git history. The secret remains accessible to anyone who clones the repository or has a prior clone.
- Running it as a one-off project without subsequent operation. Without a continuous cycle, 6 months later it is back to where it started.
Quick glossary of NHI jargon
NHI
Non-Human Identity. Identity that authenticates against a system without being a person.
Service Account
Account in a directory (AD, Entra ID) used by applications or automated processes.
OAuth app
Application registered in an identity provider (M365, Google, etc.) with consent to access APIs on behalf of the tenant.
API key
Static key issued by a SaaS or cloud provider to authenticate API requests.
Workload Identity
Identity assigned to a workload (K8s pod, lambda, function) that authenticates without a static secret via federation.
PAT
Personal Access Token. Token issued to a user for programmatic use on GitHub/GitLab/Atlassian. Usually inherits broad permissions.
Vault / Secrets Manager
Centralised secrets manager with API, access control, auditing and rotation. HashiCorp Vault, AWS Secrets Manager, Azure Key Vault, GCP Secret Manager, CyberArk.
gMSA
Group Managed Service Account. AD service account with a password automatically managed by the domain. Useful for on-prem services.
IRSA / Workload Identity
AWS and GCP mechanisms for Kubernetes pods to assume cloud roles without static secrets.
Admin Consent Workflow
Policy in Entra ID/Google Workspace requiring an administrator to approve new OAuth apps before they receive consent.
Short-lived token
Token with short expiry (minutes/hours) renewed via refresh token or federation. Reduces misuse window.
Workload federation
Pattern that replaces static secrets with trust based on the workload's identity (OIDC, certificates). Cloud-native.
Related services at Hard2bit
IAM
Parent service for human identities. NHI is the sister discipline focused on non-human ones.
View →
Microsoft 365 security
A large share of many organisations' critical NHIs live in M365: OAuth apps, service principals, service accounts.
View →
Source code security audit
Where we find most hardcoded secrets. Regular coordination with NHI for cleanup and rotation.
View →
API security audit
APIs authenticated with NHI tokens are natural targets if tokens are poorly governed.
View →
Integrated audit
When NHI is part of a broader scan also covering infrastructure, human identity and processes.
View →
Systems hardening
System hardening also covers local and service identities of the operating system itself.
View →
Attack surface management
Detection of publicly leaked secrets, exposed repositories, tokens in public commits.
View →
Third-party risk management
External supplier integrations generate NHIs whose security depends on the third-party programme.
View →
Incident response
If the audit reveals active compromise (token used by an attacker), immediate escalation to response.
View →
Frequently asked questions
What exactly is a non-human identity (NHI)?
Any identity that authenticates against a system without being a person: service accounts in Active Directory or Entra ID, OAuth tokens for SaaS applications, API keys, OIDC client secrets, client certificates, workload identities (Kubernetes ServiceAccounts, AWS/GCP/Azure IAM roles, managed identities), personal access tokens (PAT) issued to integrations, RPA or CI/CD pipeline credentials. In most organisations the NHI:human ratio sits between 20:1 and 50:1. And it grows by itself.
Why has it become an urgent problem?
Three causes. First, silent multiplication: each new SaaS tool, integration or microservice creates identities no one counts. Second, persistence: NHIs are rarely deleted when an integration is disconnected or a supplier walks away. Third, missing controls: many have no MFA, their rotation is manual and forgotten, and they receive broad permissions 'just in case'. When an attacker compromises an active NHI with excessive permissions, there is no anomalous behaviour alert as there would be with a human user.
How is this service different from traditional IAM management?
Traditional IAM was designed for human users: provisioning, password authentication, MFA, joiners/movers/leavers, periodic reviews. NHIs follow different rules: their lifecycle is not tied to HR, the typical controls (MFA, password rotation) do not apply directly, they require automated secrets rotation, OIDC/SAML federation or workload identities, and finding a functional owner is hard. The service covers the full NHI-specific lifecycle: discovery, owner attribution, secrets governance, least privilege, monitoring and safe decommissioning.
What exactly does your service include?
Five phases. Discovery: consolidated NHI inventory across cloud (AWS/GCP/Azure), SaaS (Microsoft 365, Google Workspace, Salesforce, Slack, GitHub), on-prem (AD, databases, legacy systems) and code (secrets in repos). Attribution: each NHI to a functional owner with expiry. Secrets governance: deployment or reform of a secrets manager (Vault, AWS Secrets Manager, Azure Key Vault, GCP Secret Manager) with automated rotation. Privilege reduction: moving from excessive permissions to real least privilege, with historical usage analysis. Monitoring: alerts on anomalous use, expiry, pending rotation, orphan identities.
How much does it cost and how long does it take?
Typical deployment programme: 8-16 weeks for a mid-sized organisation (500-3,000 employees, 5-20 main SaaS, multi-cloud), with 1-2 consultants. Indicative cost: €35-90k. Before quoting we run an initial 1-2 week diagnostic to size NHI volume and complexity. Without it, any figure is a guess. Subsequent operation (monitoring + rotations + NHI onboarding/offboarding) is delivered as a monthly subscription or handed over to the internal team with training.
Do we need to change our secrets manager?
Not necessarily. If you already use HashiCorp Vault, AWS Secrets Manager, Azure Key Vault, GCP Secret Manager, CyberArk or similar, we work with what is in place. We assess it during the initial diagnostic. If there is no manager or the existing one is insufficient (typically: environment variables in production, deployed .env files, GitHub Actions secrets without rotation, secrets in old Jenkins pipelines), we recommend one appropriate to your stack and volume, with clear criteria: native integration with your main cloud, SCIM or federation support, automated rotation for the most common providers, and predictable total cost.
Does it serve as evidence for ISO 27001, ENS, NIS2 or DORA audits?
Yes. ISO 27001:2022 (A.5.16 Identity management, A.5.17 Authentication information, A.8.2 Access privileges) explicitly covers non-human identities. ENS (op.acc.1, op.acc.4, mp.info.4) requires full identity and key management. NIS2 art. 21.2.i requires multi-factor or continuous authentication and encryption where appropriate. DORA art. 9 + RTS on ICT risk management covers application identities. We deliver traceable evidence of inventory, owners, rotation, least privilege and monitoring, ready for the auditor.
How do you manage identities for third-party integrations we do not control?
It is one of the critical points. When you integrate a third-party SaaS with your Microsoft 365 or Google Workspace via OAuth, that SaaS receives a token with permissions that persist with no one controlling its rotation. We cover this at two levels: OAuth apps governance (inventory, periodic review of excessive scopes, approval policy for new integrations, automatic disabling of apps with no recent use) and, where it exists, integration with CASB or SaaS management. For legacy integrations with long-lived API keys, we plan transition to short-lived tokens with automated rotation.
And the hardcoded secrets already sitting in code and Git history?
We coordinate with a code audit. Full Git history scan with tools like Gitleaks/TruffleHog, not only HEAD. Each found secret gets validated (still active?), rotated immediately at the corresponding provider, removed from current code and, depending on risk and repository type, purged from Git history (git filter-repo + force-push + team notification). In parallel we deploy pre-commit hooks that block new secrets before they reach the repo, plus CI rules that fail the build if they detect secret patterns.
How do we start a project with Hard2bit?
A 30-minute call to understand the ecosystem (cloud, main SaaS, development stack, current IAM tool, secrets manager if any) and the reason for looking at the service (compliance, recent incident, modernisation). If it fits, a 1-2 week initial diagnostic with read access to cloud and IAM to size real NHI volume. From there we issue a firm proposal: scope, window, team, deliverables and fixed price. No commitments until signature. If we see the project should be combined with prior IAM consolidation or a code audit, we will say so honestly.
Do you know how many non-human identities you have?
30-minute call to understand the ecosystem and the reason. Initial 1-2 week diagnostic to size real volume. Firm proposal after the diagnostic. No commitments until signature. Standard NDA before any first access.