Originally published by Aembit.
For many of today’s hybrid and data-driven enterprises, non-human identities (NHIs) – often referred to as machine and service accounts – are emerging as one of the most overlooked risks.
While much attention has been devoted to securing human credentials, countless application-to-application connections and service accounts remain dependent on static and inadequately managed credentials, creating significant blind spots and necessitating the establishment of the first-ever OWASP NHI Top 10 list.
As with any emerging threat, early mitigation efforts often start as voluntary best practices but quickly find their way into compliance mandates. The writing is on the wall. Only one in five organizations express strong confidence in their non-human IAM practices, while 24% report little to no confidence – a glaring gap that auditors are increasingly likely to address as compliance returns as a top priority for security leaders amid increased scrutiny from boards, tighter insurance requirements, and rising customer demands for data protection
Until now, most enterprise attention on NHIs has been focused on inventory and monitoring, led by identity governance and administration (IGA) solutions. While these tools help track service accounts and machine identities, they don’t solve the real security challenge: access control, authentication, and enforcement. That responsibility still falls on the end-user – and most organizations still handle it in a piecemeal, manual fashion.
That’s where PCI DSS 4.0 steps in. Beginning March 31, previously recommended best practices for securing NHIs will become mandatory. PCI isn’t just flagging these identities as a concern – it’s explicitly stating that non-human identities pose a greater risk than user accounts.
“Systems and application accounts pose more inherent security risk than user accounts because they often run in elevated security context, with access to systems that may not be typically granted to user accounts, such as programmatic access to databases.”
– PCI DSS 4.0
This inherent risk is exacerbated by the widespread reliance on legacy, long-lived credentials and the limited visibility and enforcement controls many organizations have over these accounts. These gaps create an ideal attack surface, making non-human identities prime targets for exploitation.
PCI DSS is famously prescriptive – and strict. This change signals broader regulatory trends that security and compliance leaders should expect to see reflected in other mandates, including the EU’s General Data Protection Regulation (GDPR) and the just-enacted Digital Operational Resilience Act (DORA).
Let’s break down where NHIs take center stage in PCI DSS 4.0—and how organizations can move beyond fragmented security approaches to meet these new mandates.
1) Requirement 2: Apply Secure Configurations to All System Components
Mandate: Secure configurations must be enforced for all system components, including non-human identities. Default passwords must be eliminated, and access must be locked down to prevent unauthorized use.
Key Sections:
- 2.2: Requires hardened configurations for system components, including NHIs.
- 2.3: Eliminates default passwords for application and system accounts.
2) Requirement 7: Implement Strong Access Control Measures
Mandate: NHIs must follow least-privilege access controls — just as user accounts do — to prevent excessive permissions and the potential for lateral movement.
Key Sections:
- 7.2.5 & 7.2.5.1: Enforce role-based access control (RBAC) and require justification for each NHI’s access.
3) Requirement 8: Identify Users and Authenticate Access to System Components
Mandate: NHIs must have strong authentication mechanisms in place; static credentials are not sufficient.
Key Sections:
- 8.6.1–8.6.3: Requires unique credentials for NHIs, regular rotation of secrets, and secure authentication (e.g., tokens, certificates).
4) Requirement 10: Regularly Monitor and Test Accounts
Mandate: NHIs must be logged, monitored, and audited to detect anomalies and ensure compliance.
Key Sections:
- 10.2: Requires logging of all NHI activities.
- 10.5: Enforces retention and protection of audit logs.
As non-human identities step into the compliance spotlight, organizations face a critical question: How can they align with these new mandates without adding undue complexity to their workflows?
For many, the answer lies in moving beyond manual processes, static secrets, and sprawling service accounts toward solutions that enforce least-privilege access, automate credential management, and provide real-time visibility into every interaction. Below, we outline essential steps to satisfy PCI DSS 4.0’s NHI requirements—and how a non-human IAM approach can help organizations meet and exceed them.
1) Unique, Strong Credentials
PCI DSS 4.0 Expectation: NHIs must use unique credentials, eliminating shared or default passwords.
How to Address It:
- Replace long-lived, static passwords with ephemeral tokens or certificates to minimize credential reuse risks.
- Reconfigure legacy applications to use per-session authentication mechanisms instead of hardcoded credentials.
- Retire shared “super-service accounts” in favor of unique identities for each application or system.
2) Secure Storage and Transmission
PCI DSS 4.0 Expectation: Credentials must be encrypted at rest and in transit.
How to Address It:
- Use AES-256 encryption to store credentials securely.
- Enforce TLS for all credential issuance and retrieval to prevent interception.
- Avoid storing credentials in configuration files or environment variables—this is now a direct compliance failure.
3) Least Privilege and Role-Based Access
PCI DSS 4.0 Expectation: NHIs should only have the access strictly necessary for their function.
How to Address It:
- Define granular policies for each NHI, restricting access to only required resources.
- Continuously review and audit access levels to prevent privilege sprawl.
- Policy-driven access ensures compromised NHIs have limited impact.
4) Continuous Rotation and Quick Revocation
PCI DSS 4.0 Expectation: Credentials must be rotated regularly, and compromised NHIs should be disabled immediately.
How to Address It:
- Automate credential rotation with ephemeral tokens that refresh per session.
- Ensure fast NHI deactivation workflows to mitigate detected threats.
5) Comprehensive Logging and Monitoring
PCI DSS 4.0 Expectation: Every NHI access attempt must be logged, and anomalies must be flagged.
How to Address It:
- Maintain detailed audit logs capturing requesting identity, timestamps, and accessed resources.
- Integrate logs into centralized monitoring platforms to enable real-time threat detection.
PCI DSS 4.0 sets a high bar for managing non-human identities – compelling organizations to rethink how they secure service accounts and machine-to-machine communications. Adopting a non-human IAM strategy – one that authenticates client workloads, checks access policies, authorizes access, and transitions to short-lived credentials – allows you to move beyond static secrets, implement real-time access controls, and gain the visibility needed to meet compliance requirements while strengthening overall security.
Think of it like managing user access: you wouldn’t rely on static passwords and excessive permissions for employees, so why do the same for your workloads?
The shift is clear: success under PCI DSS 4.0 isn’t just about managing credentials – it’s about managing access. By doing so, you’ll not only meet the demands of PCI DSS 4.0 but also build the foundation for a more secure, resilient, and identity-first future.
About the Author
Dan Kaplan is your friendly neighborhood content marketing director at Aembit. Based in New York but operating remotely, he’s here to tell non-human IAM stories to the world, designed to educate, inspire — and even entertain. Before this, he held a similar role at Google Cloud, which followed stints at Siemplify and Trustwave, where he oversaw content initiatives. He planted his roots in cybersecurity as a reporter and editor at SC Media.
0 Comments