Non-Human Identity Secrets Management for 2026 Audits

The 02:13 alert no one could attribute

At 02:13 on a Tuesday morning, the security operations channel lights up. A production database export has started from an internal automation account. The access path is legitimate. The token is valid. The source IP belongs to a cloud runner used by the engineering team. No malware is visible. No phishing report exists.

The CISO asks the first obvious question: “Who owns this identity?”

Silence.

The DevOps lead remembers that the token was created during a customer migration two years ago. The platform team says it may be used by a billing integration. The database administrator says it has read access because removing it once broke a nightly job. Legal asks whether personal data was involved. Compliance asks whether this is a reportable incident under NIS2, DORA or GDPR. The auditor asks for evidence that service accounts, API keys, certificates and CI/CD secrets are inventoried, reviewed, rotated, monitored and revoked.

By 09:00, the draft audit finding is already taking shape. A hardcoded, non-rotated API key was discovered in a forgotten microservice. It grants broad access to a production customer transaction database. The developer who created it left two years ago. The system has no named owner, no documented purpose, no rotation record and no monitoring rule.

This is the non-human identity problem in 2026.

Most organisations have improved human access control. They have MFA, joiner-mover-leaver workflows, privileged access reviews and identity provider logs. But machine identities have multiplied faster than governance. Service accounts, workload identities, API keys, OAuth tokens, SSH keys, certificates, Kubernetes secrets, SaaS integration tokens, robotic process automation accounts and CI/CD deployment credentials now perform critical business actions without being “users” in the human sense.

For SaaS providers, fintechs, managed service providers, cloud operators and data-rich SMEs, unmanaged non-human identities are no longer a technical hygiene issue. They are a board-level resilience and compliance risk. NIS2 treats access control, asset management, supply-chain security, incident handling and cyber hygiene as core cybersecurity risk-management measures. DORA places ICT risk, operational resilience, incident reporting and ICT third-party risk under management body accountability for financial entities. GDPR requires controllers and processors to protect personal data and demonstrate accountability.

The hard part is not proving that secrets exist. The hard part is proving that every non-human identity has an owner, purpose, lifecycle, risk rating, approved access, secure storage method, rotation rule, monitoring coverage and revocation path.

Why non-human identities became the new privileged access problem

A non-human identity, or NHI, is any digital identity used by software, infrastructure or automated processes rather than a person. In practice, it includes service accounts used by applications, API keys used by SaaS integrations, OAuth and refresh tokens used by third-party applications, SSH keys used by automation, TLS certificates and private keys, CI/CD secrets, cloud workload identities, database connection strings, embedded credentials, RPA bot accounts and supplier-managed integration credentials.

These identities often have three characteristics that make auditors nervous.

First, they are long-lived. A human user may rotate credentials, change roles and leave through a formal offboarding process. An API token created during a release window may stay active for years because no one wants to risk breaking production.

Second, they are powerful. A deployment token can change infrastructure. A cloud service principal can create storage. A database account can export customer records. A signing key can compromise software supply-chain integrity.

Third, they are poorly attributable. Human identities are tied to HR records. Non-human identities are often tied to scripts, pipelines, suppliers, forgotten projects or undocumented integrations.

Clarysec’s Zenith Blueprint: An Auditor’s 30-Step Roadmap Zenith Blueprint calls this out directly in the Controls in Action phase, Step 22:

And don’t forget the non-human identities. This is where audits often uncover silent exposure. Are API tokens tracked? Are integration accounts tied to people, or floating in limbo? When was the last time that database access string, embedded in a decades-old script, was rotated?

Identity management is not glamorous, but it is structural. Without it, your ISMS is just a collection of locked doors, with no way to be sure who holds the keys.

That last sentence is the point. A company can have a polished access control policy and still fail an audit if machine identities are unmanaged. An ISMS that cannot explain who owns a secret, why it exists and when it was last reviewed is not yet operating as a controlled system.

ISO/IEC 27001:2022 turns secrets management into evidence

ISO/IEC 27001:2022 is effective because it does not treat secrets management as an isolated engineering task. It requires a risk-based ISMS with defined scope, interested-party requirements, leadership accountability, risk assessment, risk treatment, control selection, a Statement of Applicability and continual improvement.

For non-human identities, the organisation should not start with a tool purchase. It should start with scope and obligations.

Under ISO/IEC 27001:2022 clauses 4.1 to 4.4, the organisation determines internal and external issues, interested parties, legal, regulatory and contractual requirements, interfaces and dependencies. In the NHI context, the ISMS scope should identify cloud environments, SaaS platforms, CI/CD systems, production applications, customer integrations, data processors, managed service providers and cryptographic services where machine credentials exist.

Clauses 5.1 to 5.3 make leadership accountable for policy, resources, roles and performance reporting. This matters because NHI remediation often creates operational tension. Rotating a production database credential, replacing a legacy shared service account or enforcing vault-based secrets injection can break fragile workflows. Without executive sponsorship, teams postpone the cleanup.

Clauses 6.1.1 to 6.1.3 and 6.2 provide the control engine. The organisation defines risk criteria, identifies confidentiality, integrity and availability risks, assigns risk owners, evaluates likelihood and impact, chooses treatment options, selects controls, produces the Statement of Applicability and tracks measurable objectives.

In practical terms, a non-human identity risk treatment plan should answer:

• Which systems and business services depend on NHIs?
• Which secrets can access personal data, regulated financial services, production infrastructure or critical customer services?
• Which identities are privileged, dormant, shared, supplier-managed or unmanaged?
• Which controls reduce risk, such as vaulting, rotation, least privilege, expiry, certificate lifecycle management, CI/CD scanning, monitoring and emergency revocation?
• Which residual risks require business approval?

ISO/IEC 27002:2022 then provides the Annex A control catalogue. The most relevant controls include 5.9 Inventory of information and other associated assets, 5.15 Access control, 5.16 Identity management, 5.17 Authentication information, 5.18 Access rights, 5.19 Information security in supplier relationships, 5.20 Addressing information security within supplier agreements, 5.21 Managing information security in the ICT supply chain, 5.23 Information security for use of cloud services, 5.24 Incident management planning and preparation, 5.28 Collection of evidence, 8.2 Privileged access rights, 8.3 Information access restriction, 8.5 Secure authentication, 8.15 Logging, 8.16 Monitoring activities, 8.24 Use of cryptography, 8.25 Secure development life cycle, 8.26 Application security requirements, 8.28 Secure coding and 8.31 Separation of development, test and production environments.

Clarysec’s Zenith Controls: The Cross-Compliance Guide Zenith Controls maps these ISO/IEC 27002:2022 relationships in a way that auditors and control owners can use. For control 5.16, Identity management, Zenith Controls explains the connection between identity and credentials:

Identity management provides the who, while authentication information ensures the how verifying that the person claiming an identity is legitimate. 5.16 governs identity lifecycle management, while 5.17 ensures that passwords, tokens, certificates, and other credentials are securely tied to those identities, and properly managed to support strong authentication.

That relationship is essential for NHIs. A token without an identity owner is not auditable. A service account without access review is not least privilege. A certificate without lifecycle status is not controlled cryptography. A supplier integration credential without contract terms is not effective third-party risk management.

The Clarysec control pattern: identity, secret, privilege, evidence

Clarysec implements non-human identity and secrets management through a repeatable control pattern. We do not treat “secrets” as only a DevOps concern or “service accounts” as only an IAM concern. We connect identity, secret, privilege and evidence.

The policy layer is where this becomes enforceable.

For SMEs, Clarysec’s User Account and Privilege Management Policy-sme User Account and Privilege Management Policy-sme states:

Service accounts (used by systems or applications) must be documented, restricted to specific systems, and never used for interactive logins.

This prevents the classic anti-pattern where a service account becomes a shared administrator login. It also gives an auditor a clear test: show the service account inventory, show system restriction, and show that interactive login is disabled or technically prevented.

Clarysec’s Asset Management Policy-sme Asset Management Policy-sme expands the definition of assets to include:

Digital credentials and services: domain names, digital certificates, API keys, email accounts, cloud logins

This matters because many organisations only inventory servers, laptops and applications. In 2026, an API key can be more sensitive than a laptop. A certificate private key can be a production authentication asset. A cloud login used by automation can create regulated data exposure. Treating credentials as assets is the foundation of audit-ready secrets management.

For enterprise environments, Clarysec’s User Account and Privilege Management Policy User Account and Privilege Management Policy raises the evidence bar:

The organization shall maintain a detailed inventory of all active and dormant credentials, privileged accounts, and system-level service accounts. This inventory shall be updated continuously and reviewed quarterly.

Quarterly review is where many gaps surface. Dormant credentials, orphaned service principals, old integration users, unmanaged supplier accounts and emergency tokens become visible only when someone compares the register to actual IAM, vault, CI/CD and cloud records.

Secrets are authentication information, not developer convenience

The most dangerous phrase in secrets management is “temporary key.”

Temporary keys become permanent. Test credentials reach production. Source code reveals tokens. Build logs expose passwords. Support teams share certificates through tickets. Developers copy environment files into chat. A contractor creates a cloud service principal and leaves.

The Zenith Blueprint, Controls in Action phase, Step 22, describes authentication information broadly:

This control isn’t about passwords alone, although passwords are certainly part of the picture. It’s about every credential used to assert identity: passwords, PINs, cryptographic keys, biometric templates, smartcards, tokens, certificates, OAuth tokens, SSH keys, API secrets. These are the keys to the kingdom, and Control 5.17 ensures that those keys are treated with the seriousness they deserve.

Let’s be clear: poor authentication management remains one of the top root causes behind breaches. Weak or shared passwords. Hardcoded credentials in source code. Unchanged default logins on admin portals. Certificates with expired or unknown ownership. In every one of those cases, it’s not the identity that failed, it’s the failure to protect and govern the mechanism used to prove that identity.

Clarysec policies translate that into operational rules.

The Cryptographic Controls Policy-sme Cryptographic Controls Policy-sme states:

Keys must not be stored in plain text or embedded in source code, documents, or emails

The Secure Development Policy-sme Secure Development Policy-sme states:

No hard-coded credentials or secrets in source code

For enterprise teams, the Secure Development Policy Secure Development Policy states:

Secrets must not be hardcoded or stored in plain text in repositories.

And the Application Security Requirements Policy Application Security Requirements Policy is even more direct:

The storage of passwords or cryptographic keys in plain text is strictly prohibited.

These policy clauses create a clear audit trail. Security teams can test repositories, CI/CD variables, container images, configuration stores, issue trackers, documentation platforms and logs against explicit requirements. They also support GDPR Article 32 security of processing, because secrets exposure can lead directly to unauthorised access to personal data.

Enterprise cryptographic governance also needs ownership. Clarysec’s Cryptographic Controls Policy Cryptographic Controls Policy requires:

A centralized Key Management Register must be maintained to record all cryptographic keys, their lifecycle status, assigned custodians, and usage contexts.

For non-human identities, that register should connect certificate keys, signing keys, API keys and cloud-managed keys to the broader NHI register. The auditor should be able to trace a production certificate from business service, to owner, to custodian, to expiry, to rotation evidence, to incident response procedure.

NIS2, DORA and GDPR: one evidence model, many regulators

Non-human identity governance is a cross-compliance problem because the same failure can trigger multiple obligations.

A leaked API token in a SaaS provider may cause service disruption under NIS2, personal data exposure under GDPR and contractual incident reporting to financial customers under DORA supply-chain expectations. A compromised CI/CD secret at an ICT service provider may affect customer resilience, software integrity and operational continuity. A forgotten supplier integration account may create access to regulated systems without proper due diligence or contract controls.

NIS2 Article 21 requires appropriate and proportionate technical, operational and organisational measures. The minimum areas include risk analysis, information-system security policies, incident handling, business continuity, supply-chain security, secure acquisition, development and maintenance, vulnerability handling, effectiveness assessment, cyber hygiene, cryptography, HR security, access control and asset management, and where appropriate MFA or continuous authentication. Non-human identities sit across almost all of those areas. NIS2 Article 23 also creates staged significant incident reporting, including early warning within 24 hours, incident notification within 72 hours and a final report no later than one month after the incident notification.

DORA applies from 17 January 2025 and covers ICT risk management, major ICT-related incident reporting, operational resilience testing, information sharing and ICT third-party risk. Articles 5 and 6 require governance, management body accountability and a documented ICT risk management framework. Article 8 requires identification of ICT-supported business functions, information assets and dependencies. Articles 17 to 19 require incident management, classification and reporting. Articles 28 to 30 require ICT third-party risk management, contractual registers, due diligence, security standards, audit rights, incident support, subcontracting controls and exit strategies.

GDPR applies wherever personal data is processed under its territorial scope. Article 5 requires integrity, confidentiality and accountability. Article 32 requires appropriate technical and organisational measures for security of processing. If a service account or API key can access personal data, unmanaged secrets become a privacy control failure, not only an IT issue.

The same evidence can support ISO/IEC 27001:2022 certification, NIS2 supervision, DORA examinations and GDPR accountability when it is structured correctly.

NIST CSF 2.0 can be used as a communication layer for the same evidence. Its GOVERN function covers stakeholder expectations, legal and contractual obligations, risk appetite, leadership accountability, policy and oversight. Its operational outcomes cover asset inventories, supplier-provided services, identity and credential management, least privilege, data security, logging, monitoring, incident response and recovery.

COBIT 2019 and ISACA-style assurance teams will usually look at governance and process capability. They will ask whether responsibility is assigned, whether controls are embedded in operational processes, whether exceptions are approved, whether metrics are reported to management and whether evidence demonstrates repeatability rather than a one-time cleanup.

A practical sprint to build a non-human identity register

A practical Clarysec engagement often starts with a focused sprint, not a six-month tooling programme. The goal is to produce a defensible NHI register, risk ranking and remediation plan that can feed the ISO/IEC 27001:2022 risk treatment plan and Statement of Applicability.

Start with one business service, such as a customer billing platform, trading application, patient portal or SaaS tenant management system. Include production, staging, CI/CD, cloud infrastructure, monitoring tools, databases, SaaS integrations and supplier-managed services.

Tie this to Zenith Blueprint, Risk Management phase, Step 14, where Clarysec aligns treatment policies with regulatory cross-references. In that step, secure development and pipeline controls include no hardcoded secrets, peer review, automated static analysis, dependency scanning, separation of development, testing and production, MFA for pipeline access, build artifact integrity and CI/CD logging.

Collect identities and secrets from the identity provider, cloud IAM, secrets vault, Kubernetes, CI/CD variables, repository settings, database users, SaaS admin consoles, certificate management tools and supplier documentation.

Risk-rate identities that have production access, privileged rights, personal data access, critical or important function dependency, supplier control, long-lived tokens, no owner, no rotation, no monitoring or hardcoded storage. Use ISO/IEC 27001:2022 risk criteria to score likelihood and impact. Use DORA critical or important function analysis where applicable. Use GDPR impact considerations where personal data is accessible. Use NIS2 service impact where disruption or customer harm is plausible.

For each high-risk NHI, apply treatment actions. Move secrets from source code, documents and CI/CD plaintext variables into a vault or managed secret store. Replace shared service accounts with unique workload identities. Disable interactive login for service accounts. Apply least privilege and environment-specific credentials. Configure rotation, expiry and emergency revocation. Bind secrets to owners and custodians. Add logging for authentication, token use and sensitive actions. Add alerting for anomalous geography, unusual time, unusual volume or new resource access. Update supplier contracts for credential handling, incident support and audit rights. Document exceptions with risk owner approval and expiry date.

The Test Data and Test Environment Policy Test Data and Test Environment Policy supports environment separation:

Integration with CI/CD pipelines must enforce the separation of environments and authentication credentials.

That clause is frequently decisive. If development, test and production share secrets, a low-risk environment can become a production breach path.

The sprint should end with an evidence pack, not only a list of findings. Include the NHI register export, risk assessment entries, treatment plan, Statement of Applicability mapping, policy references, vault screenshots, rotation logs, access review approvals, CI/CD secret scanning results, monitoring rule definitions, supplier credential responsibility matrix, incident runbook and exceptions with owners and expiry dates.

Logging and detection: proving that machine identity use is visible

A machine identity that is well inventoried but invisible in logs remains dangerous. Detection is part of the control story.

Clarysec’s Logging and Monitoring Policy-sme Logging and Monitoring Policy-sme includes authentication evidence:

Authentication logs: Successful and failed login attempts, session duration, MFA usage

For NHIs, adapt this requirement to machine authentication. You may not have MFA usage for a workload identity, but you should have authentication events, token use, certificate use, API call metadata, source workload, destination service, token lifetime, failure events and privileged actions.

In Zenith Controls, ISO/IEC 27002:2022 control 8.2, Privileged access rights, is tied to logging and monitoring because privileged accounts require detailed records and oversight. Zenith Controls also ties 8.2 to identity management, access rights, information access restriction and secure authentication. For auditors, this means privileged non-human identities should be reviewed and monitored with the same seriousness as human administrators, sometimes more.

Good monitoring questions include:

• Did a service account authenticate from an unexpected workload or IP range?
• Did an API key access a new endpoint or dataset?
• Did a certificate get used after replacement?
• Did a CI/CD token deploy outside an approved pipeline?
• Did a read-only account attempt write operations?
• Did a dormant credential become active?
• Did a supplier integration access data outside agreed hours or volumes?

When the 02:13 alert occurs, you need to answer what identity was used, what secret authenticated it, what access rights were exercised, what data or systems were affected, whether the activity was expected, which owner can validate it and whether incident reporting thresholds are met.

The auditor’s lens: the same process, different questions

The strongest audit position is not “we comply with everything.” It is “we operate one controlled process that produces evidence for multiple obligations.” Different auditors will inspect that process differently.

Across those perspectives, the recurring findings are predictable: no single NHI inventory, no owner for machine identities, secrets stored in code or documentation, shared credentials across environments, no rotation or expiry, supplier-managed credentials outside access reviews, monitoring that covers humans but not machines, and incident runbooks that ignore secret leakage.

Each finding maps naturally to Clarysec controls, policies and remediation templates. More importantly, each can be converted into measurable evidence within the ISMS.

How Clarysec helps you get audit-ready

Clarysec’s approach is practical because it starts with the evidence auditors will request and works backward into controls, policies and operational routines.

In the Zenith Blueprint, Controls in Action phase, Step 19, Clarysec gives direct guidance for machine-to-machine authentication:

For machine-to-machine authentication, such as service accounts or API calls, keys, certificates, and tokens must be protected just as rigorously. Avoid embedding credentials in code. Use secrets management systems or vaults to store and rotate them securely.

A typical Clarysec non-human identity workstream includes NHI discovery across cloud, SaaS, CI/CD, repositories, vaults and databases, policy gap assessment against Clarysec SME or enterprise policy sets, ISO/IEC 27001:2022 risk assessment and treatment mapping, Statement of Applicability updates, NIS2, DORA, GDPR and NIST CSF evidence mapping, NHI register design, key management register alignment, secrets scanning, access review processes, supplier credential responsibility matrices, incident runbooks and audit packs with screenshots, exports, logs, approvals and exception records.

For SMEs, the approach is proportionate. A 70-person SaaS provider does not need the same tooling footprint as a global bank, but it does need ownership, policy, risk treatment and evidence. For regulated financial entities and ICT providers, the same model scales into DORA critical function mapping, third-party risk governance and resilience testing.

If your next audit is in 2026, do not wait for the auditor to discover non-human identities for you. Start with one critical service and ask five questions:

1. Do we know every service account, API key, token, certificate and CI/CD secret used by this service?
2. Does every NHI have a named owner, custodian, purpose and risk rating?
3. Are secrets vaulted, rotated and protected from source code, documents, emails and plaintext storage?
4. Are privileged machine identities reviewed, monitored and restricted from interactive use?
5. Can we produce evidence for ISO/IEC 27001:2022, NIS2, DORA and GDPR from one controlled process?

Use Zenith Blueprint: An Auditor’s 30-Step Roadmap Zenith Blueprint to structure your ISMS implementation journey. Use Zenith Controls: The Cross-Compliance Guide Zenith Controls to connect ISO/IEC 27002:2022 identity, authentication, privilege, logging, cryptography, secure development and supplier controls to regulatory evidence. Use Clarysec’s SME and enterprise policy library, including the User Account and Privilege Management Policy-sme User Account and Privilege Management Policy-sme, Cryptographic Controls Policy Cryptographic Controls Policy, Secure Development Policy Secure Development Policy and Application Security Requirements Policy Application Security Requirements Policy, to convert good intentions into enforceable requirements.

The 02:13 alert will happen somewhere. The question is whether your organisation can answer, with evidence, who held the key, what it opened, why it existed and how fast you can make it safe.