Welcome to our NHI security series. In our previous guides, we looked at how to build an NHI security strategy and how to apply practical security principles to existing frameworks. In this (very long) article, I will focus on compliance. It is one of the biggest areas of concern for CISOs, security architects, and IAM teams, and it is now impossible to treat NHIs as an afterthought during regulatory preparation.

I will walk through the major regulatory frameworks, explain how they apply to NHIs, and outline what auditors will expect to see.

Note: Throughout my article, I use the term NHI (non-human identities) to refer to machine identities such as service accounts, workloads, processes, and application identities. Most of the regulations apply to AI agents and agentic systems as well.

 

Non-human identities under the microscope

According to the Non-Human Identity Management Group, “two-thirds [of organizations] don’t know how to fully address risks, and only 15% are confident in their ability to secure NHIs.”

And they’re not the only ones worried about NHI security. This year, OWASP put out its first list of top NHI security risks. And regulatory bodies such as the SEC, ECB, and FCA are taking a closer look as well. New compliance reviews could include now-standard questions like:

• Do you have an inventory of all NHIs, and can you map each one to an owner and a business purpose?
• Are machine credentials rotated, vaulted, and never shared between systems?
• Can you show that over-privileged or unused NHIs are detected and remediated?

If you fail to demonstrate compliance, you’ll be in trouble. A sad example of exactly this is the Capital One case. In 2020, the U.S. Office of the Comptroller of the Currency issued an 80 million USD penalty after an attacker exploited a cloud configuration weakness and then used an over-privileged workload identity to pull regulated customer data.

The security issue was serious, but the compliance issue was even more telling. A single machine identity had enough unchecked access to move across systems and reach data it should never have reached. This is exactly the type of gap regulators point to when they ask about rotation, attribution, auditability, and least privilege for NHIs. You can steal this horror story for your security meetings 😄.

Cases like this help explain to leadership why NHI compliance needs attention and why NHIs should already sit inside the IAM strategy, not be treated as a secondary problem.

 

What compliance frameworks should you use for NHIs?

Almost every team I speak with struggles with the same question: “Which frameworks actually apply to our NHIs?” The answer depends on your sector, geography, and whether you handle financial data, health data, personal data, or run SaaS for enterprise customers.

To make it simpler, I grouped the major regulations into four buckets. This does not replace legal advice, but it gives you a solid mental model for understanding your NHI obligations:

Framework Type	Description
Universal frameworks	Universal frameworks like ISO 27001 and SOC 2 apply to most SaaS and cloud companies. If your NHIs access production systems, these standards already expect them to be governed and logged.
Sector-specific frameworks	Sector-specific frameworks such as PCI DSS and HIPAA apply when NHIs touch cardholder data or protected health information. These frameworks are very prescriptive and often expose gaps first.
Service-specific frameworks	Service-specific frameworks such as SOC 2 hit any company selling to enterprise customers.
Location-specific frameworks	Location-specific frameworks such as GDPR, DORA, and NIS2 apply based on where you operate or where your customers are located. These include NHIs indirectly but clearly.

Even though half of the regulations in this guide don’t mention NHIs explicitly, they all impact how an organization should approach NHI security.

A note on taxonomy: Different frameworks use different terms for NHIs, including machine identities, workloads, processes, and service accounts. When terminology differs, I highlight the exact terms used to avoid confusion. One more note. This article is long and a bit too detailed in places, but that is the side effect of spending too much time inside compliance frameworks 🙂 Now let’s get into compliance details.

 

Payment Card Data Security Standards (PCI DSS) for non-human identities

If you work in fintech, banking, or payments, PCI DSS is one of the frameworks you live with every day. It sets the security baseline for anything that processes, stores, or transmits cardholder data. What many teams still underestimate is how deeply PCI DSS applies to non-human identities. In v4.0.1, PCI treats service accounts, application accounts, and system processes the same way it treats human users. If an NHI touches payment infrastructure, it is in scope.

PCI DSS is very specific about what it expects. NHIs must have unique identification. They must authenticate securely. Their access must follow least privilege. And every action taken by an automated identity must be logged and attributable. For compliance teams, this is the part that usually exposes gaps, because many NHIs (machine identities 🤖) were created by engineering years ago and never integrated into IAM or compliance workflows.

A few PCI DSS areas matter most for fintech teams:

• Requirement 7 (Restrict access to cardholder data, 7.1 and 7.2) focuses on authorization. It asks whether every system and application account has only the access it needs and whether that access is justified and reviewed. PCI explicitly includes application and system accounts here, which covers NHIs. This is where over-privileged or legacy NHIs usually surface, especially those with broad access to payment systems or unclear ownership.

• Requirement 8 (Identify and authenticate access, Preamble, 8.2, 8.3, 8.6) governs identity and authentication for both humans and NHIs. PCI DSS v4.0.1 makes it explicit that identification rules apply to “an individual or process,” which means NHIs must follow the same identity governance as human users. Each NHI must have a unique ID. Shared service accounts are only allowed under tightly controlled and documented exceptions. PCI also prohibits hardcoded passwords in scripts or configuration files and requires secure storage, rotation, and lifecycle management for all machine credentials.

• Requirement 10 (Log and monitor all access, 10.2 and 10.3) ensures full auditability. All actions taken by NHIs must be logged, timestamped, and attributable to the individual identity. Logs must be protected from tampering and retained according to PCI requirements. If an NHI interacts with cardholder data or systems connected to the CDE, its activity must be clear enough to reconstruct events during investigations or audits.

An NHI that triggers a payment workflow, reconciles transactions, calls a billing API, or even pulls metadata from a cardholder-connected system becomes a compliance asset. When these identities are unmanaged or invisible, they create the exact gaps auditors look for!

 

Digital Operational Resilience Act (DORA) for non-human identities

DORA sets out how EU financial institutions must manage access, identity governance, and operational risk across both human activity and machine-driven systems. The regulation refers to “natural persons and systems,” which means NHIs such are included by definition whenever they interact with financial workflows.

DORA’s main pressure points relate to identifying every identity, monitoring its activity, and proving that access decisions are intentional and controlled. This often exposes long-running internal automations or service accounts that were never documented or reviewed in formal governance processes.

Several parts of DORA are especially relevant for NHIs:

• Article 3 and Article 6 (Risk management and assurance mechanisms). NHIs must be included in risk assessments and treated as potential sources of operational exposure. Fintech companies must show that non-human identities cannot access data or systems beyond their purpose.

• Article 11 (Robust controls, testing, oversight) requires testing and validating controls that apply to automated workflows and machine-level access. NHIs must be covered by resilience testing to ensure they cannot bypass safeguards.

• Article 20 (Access control for persons and systems) requires unique identification, authentication, and lifecycle management for all identities. Each system identity must be governed through documented responsibilities, ensuring a designated person reviews and maintains its access.

• Articles 21–23 (ICT operations, detection, and incident reporting) expect financial institutions to monitor automated activity, detect anomalies, and tie incidents back to specific identities. NHIs need structured logging and visibility (same as for PCI DSS).

• Article 33 (Logical access control requirements) covers rules for granting, reviewing, and revoking access. Over-privileged NHIs, shared credentials, or unsegmented system accounts are all red flags under this article.

Any automated identity that interacts with EU financial systems, transaction chains, or internal operational workflows must be governed under DORA. If you are navigating DORA alongside NIS2, CRA, or sector-specific rules, this breakdown helps clarify how these frameworks intersect:

 

NIS2 (Network and Information Security Directive) compliance for non-human identities

NIS2 is the EU-wide cybersecurity directive for essential and important companies. It applies to sectors like cloud services, digital infrastructure, software providers, financial services, and any organization classified as “critical” by national regulators in each EU country.

A recent example is Germany’s NIS2 Implementation Act. Adopted in November 2025, it expanded the number of regulated companies from 4,500 to almost 29,500. Your NHIs may now be in scope for this regulation if you operate in Germany.

While the directive does not mention NHIs directly, its controls clearly include automated “systems”, “service accounts”, and “machine-to-machine integrations”. If a system identity connects to production services, handles data, or supports critical functions, it sits inside NIS2 expectations:

• Article 21 (Cybersecurity risk management) covers access control, authentication, and asset governance across all systems. NHIs must be identified, documented, and restricted to the minimum access needed for their role.

• Article 23 (Incident reporting) focuses on rapid detection and investigation of security events. NHIs must produce clear and attributable logs so automated actions can be traced during an incident.

• Article 24 (Supply-chain and third-party risk) addresses risks created by external providers and connected services. NHIs calling third-party APIs must be monitored and included in supplier risk evaluations.

• Article 25 (Policies and governance) defines internal security responsibilities and processes. NHIs must appear in IAM policy, with lifecycle management and periodic reviews documented.

• Article 27 (Cryptography and secure communication) sets expectations for encryption, keys, and secure machine-to-machine communication. NHIs using tokens or certificates must rely on controlled and well-managed key material.

When I was researching NIS2, I found a visualisation that explains the overlap between NIS2 and ISO 27001 in a very simple way. I will link it here before we move to ISO 27001 and NHIs. After going through so many regulations, it also became clear that once you meet a few of them properly, the others often require far less additional work.

 

ISO 27001 compliance for non-human identities

ISO 27001 is one of the most widely adopted security standards in the world. Many companies choose it because it gives a structured way to run an ISMS and makes other certifications far easier. Even though ISO 27001 never says the words “non-human identity”, its controls definitely apply to any identity that can access systems or data.

The standard expects you to know which identities you have, how they authenticate, what they can access, and whether that access still makes sense:

• Article 5.16 (Identity management) focuses on the lifecycle of identities. NHIs must be created, updated, and removed through the same controlled process you use for employees.

• Article 5.17 (Authentication information) sets expectations for secure credentials. NHIs must use protected secrets or certificates. No hardcoded credentials and no shared keys hiding in config files.

• Article 5.18 (Access rights) covers how access is granted, reviewed, and removed. NHIs must follow least privilege and appear in scheduled access reviews. Annex A 5.15 outlines how access is governed across systems. NHIs that interact with internal or external systems must be covered by these rules.

• Annex A 8.12 (Logging and monitoring) expects companies to track system activity. NHIs must generate logs that show clear, attributable actions.

• Annex A 9 (Access control) expands on how systems and applications must enforce access rules. NHIs that log in, authenticate, or use elevated tools fall under this group of controls. There are many more details in this section:

  • Annex A 9.4 (System and application access control) describes how applications should manage authentication and authorization. NHIs used to access apps or services must be governed here.
  • Annex A 9.4.2 (Secure log-on procedures) applies when NHIs authenticate into systems or services. Their log-on flows must use secure methods and protected credentials.
  • Annex A 9.4.3 (Password management systems) applies to NHIs that still rely on secrets instead of certificates. These secrets must be stored, rotated, and protected under a formal password management process.
  • Annex A 9.4.4 (Use of privileged utility programs) applies to machine identities that can run tools with elevated privileges. Over-privileged NHIs are a common audit finding under this control. I hope I covered all subsections related to non-human identities.

• Annex A 10.1 (Cryptographic controls) focuses on key and certificate management. NHIs using tokens or certificates must use secure storage, rotation, and proper ownership.

ISO 27001 is not as prescriptive as PCI DSS or DORA, but it relies heavily on consistent and reviewable processes. Once NHIs are fully included in your Information Security Management System, you suddenly notice that most other frameworks become easier because the hard work is already done (or almost done 😄).

 

Health Insurance Portability and Accountability Act (HIPAA) for non-human identities

Now let’s switch to medtech, where HIPAA is a must. It’s a U.S. regulation focused on protecting PHI and securing any system that stores or processes it. Most people think about HIPAA in terms of human access, but many of its controls apply directly to NHIs as well.

A good example is the Anthem breach. Attackers used the credentials of a system account that had broad access to PHI. It was a non-human identity. With that one account, attackers could query and extract patient records without being noticed. The breach impacted 78.8 million people and resulted in a 16 million USD settlement. Penalties in medtech are wild.

And as with all other compliance frameworks in my guide, HIPAA never uses the phrase “non-human identity.” But it does refer to “entities”, “processes”, and “services”, which makes NHIs part of the compliance surface by default:

• Access Controls (§ 164.312(a)) focus on limiting what each identity can access. NHIs must have unique credentials so their actions can be logged and traced. They must also follow least privilege, because even one over-permissioned service account can expose sensitive PHI.

• Person or Entity Authentication (§ 164.312(d)) covers how identities authenticate into systems. NHIs must use secure credentials. No shared tokens and no hardcoded secrets in scripts or configuration files.

• Audit Controls (§ 164.312(b)) require detailed logging of system activity. NHIs must generate logs that show which identity took each action and when. These logs must support the detection of abnormal behavior, especially in workflows that move or read PHI.

HIPAA is very strict about traceability. If an automated process accesses PHI, you must be able to show who or what did it. Missing or shared machine credentials are one of the most common HIPAA findings because they break attribution.

 

The General Data Protection Regulation (GDPR) for non-human identities

GDPR covers any activity that handles personal data, whether it is done by a person or by a system running in the background. Many automated jobs, integration scripts, and service accounts handle personal information. When these NHIs read or modify personal data, they become part of GDPR compliance.

GDPR expects organisations to understand how personal data is processed and by which identities:

• Article 24 covers accountability. Organisations must be able to explain how personal data is processed and show clear records of which identity performed which operation. NHIs must be logged and linked to a defined purpose.

• Article 22 deals with automated decision making and profiling. If an NHI triggers or contributes to a decision that affects an individual, those actions must be reviewable and understandable.

• Article 25 focuses on data minimisation and access control. NHIs should have only the access needed to perform their function. Anything broader becomes a privacy and compliance risk.

GDPR is broad, but the idea is simple. Keep data access narrow, know exactly which identities are involved in processing, and make sure every automated action is traceable.

 

SOC 2 (System and Organization Controls 2) for non-human identities

SOC 2 is a widely used framework in SaaS and B2B companies, especially for teams that work with enterprise customers. It is built around the five Trust Service Criteria: Security, Availability, Processing Integrity, Confidentiality, and Privacy. SOC 2 does not separate humans from non-humans. Any identity that can access systems or data must follow the same controls.

Many SOC 2 gaps come from NHIs that hold broad permissions, live in CI systems, or power third-party integrations. If they are not monitored or documented, they break SOC 2’s expectations around accountability and least privilege:

• Access controls (CC6.1 to CC6.8) focus on restricting system access based on roles and least privilege. NHIs must have defined permissions, proper justification, and logs that show how they are used.

• Authentication and authorization (CC6.2 and CC6.3) require secure authentication for every identity. NHIs must authenticate with controlled credentials, and their permissions must map to documented policies.

• Logging and monitoring (CC7.2) expect organisations to detect suspicious activity and review logs. NHIs must generate events that make it possible to trace actions and identify anomalies.

• Change management (CC8.1) covers how system changes are reviewed, approved, and tracked. NHIs that deploy code or automate infrastructure must be included in this process.

• Vendor and third-party management (CC9.2) applies when NHIs interact with external services or APIs. These integrations must be documented, monitored, and reviewed as part of the organisation’s risk program.

This was the last framework in my list. Well done for reading till the very end! Now, let's chat a bit about preparation.

 

How to get audit-ready with your non-human identities

Regulations already place NHIs inside their scope, which means audits now do the same. Auditors expect you to show how machine identities are created, reviewed, monitored, and controlled, just like human identities.

To pass, you need precise and verifiable evidence that your NHIs follow the same lifecycle, least privilege, and logging rules required across PCI DSS, DORA, ISO 27001, and the rest.

To make this preparation easier, I outlined the key NHI practices auditors look for and the types of proof they usually ask you to provide.

NHI security practice	Demonstrating compliance
1. Credential rotation policies and enforcement evidence	Show formal policies that define rotation intervals (e.g., 90 or 180 days) backed by logs and automated audit trails that prove adherence. Tools like Vault or AWS Secrets Manager should generate verifiable rotation metadata.
2. Activity logs tied to NHI accounts	Show logs that track every action initiated by an NHI, timestamped and attributed to a unique identity. Logs should be immutable and centrally stored. Include examples where monitoring detected misuse or suspicious activity.
3. Complete inventory of NHIs	Maintain an up-to-date register of NHIs, which should include: • Creation timestamps and source system • Assigned roles and entitlements • Last usage and activity trail • Owner and business justification • Status (active, dormant, decommissioned)
4. Secrets vault configuration and audit logs	Provide evidence that secrets are managed via vaults, along with access control policies and access logs. Demonstrate RBAC enforcement and MFA usage where applicable.
5. Remediation playbooks	Show procedures on how stale or orphaned NHIs are detected and retired. Include examples of automated workflows that trigger alerts, initiate revocation, and notify asset owners.
6. Mapping to regulatory clauses	Align internal controls to the specific framework your organization is undergoing an audit for.
7. Privilege access management	Demonstrate: • Identify all privileged human and non-human accounts. • Enforcement of least privilege using role-based access and just-in-time elevation. • Your chosen PAM solution (e.g., CyberArk, BeyondTrust, or open-source tools). • MFA for human access to PAM systems, and strict credential controls for NHIs. • Enforcement of clear policies for access approval, review, and revocation. • Detailed logs and policies for auditing and documenting all privileged access to systems handling NHIs.
8. Authorization	Show: • Clear documentation of roles, permissions, and policy logic. • Logs and audit trails of how access decisions are made and enforced. • Evidence of periodic reviews of who has access to NHIs and why.

If there is one takeaway from this entire guide, it is this: NHIs behave like users, so they must be treated like users. They need owners, guardrails, and logs, not a free pass because they run quietly in the background. The good news is that once NHIs enter your IAM program, everything from audits to incident response becomes much simpler. And maybe your next compliance review will finally feel a little less painful 🙂