A Non-Human Identity represents any digital credential or identity leveraged by software, systems, or automated processes rather than human users. These identities authenticate and operate continuously, frequently with elevated access levels.
NHIs in typical German enterprises include service accounts in Active Directory, API keys for SaaS platforms and internal integrations, OAuth tokens for Microsoft 365, Salesforce, and SAP connections, SSH keys deployed across DevOps pipelines, machine certificates for TLS/mTLS authentication, RPA bot credentials, cloud IAM roles and service principals, and CI/CD secrets in GitHub Actions, GitLab, and Jenkins.
The Scale of the Problem
For every human identity, organisations maintain roughly 10–45 non-human identities. A 300-employee company manages 3,000–14,000 total identities.
Why NHIs Are More Dangerous Than Human Accounts
- No automatic rotation — Service account passwords remain unchanged for years
- No inactivity triggers — Unlike humans, service accounts operate 24/7
- Over-privileged defaults — Developers grant admin access for convenience
- Invisible to traditional PAM — Most PAM tools target human accounts
- Broken offboarding — Accounts persist after creator departure
The MusterSec Case Study
MusterSec, a mid-sized German manufacturing company with 800 employees:
- 23 legacy service accounts in AD (some from 2017 ERP migration)
- 41 API keys in application config files (several in plaintext)
- 19 OAuth tokens to disconnected third-party apps
- 15 shared SSH keys on production servers
- 18 certificates approaching expiry
- 6 RPA bot credentials with domain admin privileges
Framework Requirements
NIS2 Requirements
NIS2 Article 21(2)(i) mandates policies on cryptography and encryption, with access control requirements spanning Article 21(2)(a) covering all assets and Article 21(2)(i) explicitly including identity and access management.
ISO 27001:2022 Controls
- A.5.15 (Access Control): Enforce rules for all identities, including non-human entities
- A.5.16 (Identity Management): Full lifecycle management for service accounts
- A.5.17 (Authentication Information): Credential management including rotation and revocation
- A.5.18 (Access Rights): Least privilege application with regular reviews
BSI IT-Grundschutz
- ORP.4: Technical account management separate from human identities
- APP.2.1: Directory service management including AD service accounts
- CON.1: Certificate and key management lifecycle
- OPS.1.1.2: Service account governance and privileged access controls
Hidden Cost Structure
Breach Cost: Compromised Service Account
- €18–35K — Incident response & forensics
- €8–15K — Downtime costs
- €5–12K — Regulatory notification (NIS2 Art. 23)
Preventive Monitoring: Security Factory
- €1,500/mo — IAM Agent
- Included — Security Assessment Agent
- €1,500/mo — GRC Agent
Security Factory Agents for NHI
01. IAM Agent — Discovery & Lifecycle
Builds complete NHI inventory by querying Active Directory, scanning cloud environments, mapping API key usage, and tracking certificate expiry. Runs continuously.
02. Security Assessment Agent — Risk Scoring
Assigns risk scores based on privilege level, rotation history, usage patterns, and exposure surface. Generates prioritised remediation tasks.
03. GRC Agent — Compliance Mapping
Maps NHI data to NIS2 Article 21, ISO 27001 A.5.15–5.18, and BSI requirements. Generates audit-ready evidence.
MusterSec Implementation Results
Manual equivalent: 3–5 days and €8,000–15,000
NHI Management Playbook
Phase 1: Inventory (Week 1–2)
- Active Directory service account audit — Export non-expiring password accounts, scheduled task accounts, accounts outside standard OUs
- Cloud service principal scan — Azure, AWS, GCP enumeration cross-referenced against active workloads
- API key and secret discovery — Password managers, CI/CD systems, config files, IaC repos
- Certificate inventory — Internal PKI, public certificates, load balancer TLS, code signing
Phase 2: Risk Classification (Week 2–3)
Risk Scoring Matrix
Phase 3: Governance (Month 1–2)
- Naming convention:
SVC-AppName-Function-Environment - Ownership: Every NHI must have a documented owner
- Vault integration: CyberArk, HashiCorp Vault, or Azure Key Vault
- Rotation policy: 90-day max for passwords; 180-day max for certificates
- Offboarding trigger: Review within 24 hours of creator departure
Phase 4: Continuous Monitoring (Ongoing)
- Real-time alerting on new NHI creation (SIEM integration)
- Weekly orphaned account reports
- Monthly privilege reviews
- Quarterly access reviews (ISO 27001 A.5.18)
- Automated certificate expiry alerts (60/30/14/7 day warnings)
German Enterprise Specifics
SAP Service Accounts
SAP RFCUSER and background job accounts frequently hold cross-system access and are routinely over-privileged. Include SAP Basis accounts in scope.
Betriebsrat Considerations
Automated NHI monitoring touches BetrVG §87(1)(6). Engage Betriebsrat early — standard process for German security teams.
TISAX Requirements
VDA ISA 1.3.2 mandates privileged system account management. NHI inventory required for TISAX Level 2+ assessments.
MSP Accounts
Service accounts used by T-Systems or Deutsche Telekom MSPs remain your NHIs under NIS2. Request complete account inventory from providers.
Key Takeaways
- Average German enterprises maintain 150–300 NHIs with limited visibility
- NIS2 Article 21, ISO 27001 A.5.15–5.18, and BSI ORP.4 mandate NHI management with board-level liability
- Cost analysis: €50K+ per incident versus €1,500/month for continuous monitoring
- Three Security Factory agents handle the complete NHI lifecycle
- Discovery precedes governance — visibility is foundational
Need help implementing this?
First strategy session is complimentary. We typically respond within 4 hours.