PCI DSS for non-human identities: governing machine access end to end

Requirement 10 says keep audit trail history for at least a year, with three months immediately available. The assessment lands, the QSA asks for the access history of the service accounts that touch the cardholder data environment, and the team discovers the batch job's logs were never centralized and the runner recycled its volume in February. The evidence existed once and was not kept. PCI DSS for non-human identities is decided long before the assessment, by whether the records accrued continuously or got scrambled together at the end.

Non-human identities, service accounts, scheduled jobs, CI runners, autonomous agents, are usually the heaviest users of the CDE and the least watched. Under PCI DSS they are accounts like any other: in scope for unique identification (Requirement 8), least privilege (Requirement 7), and complete, retained, protected logging (Requirement 10).

Why the last-minute scramble loses

The scramble loses because PCI DSS logging is not a one-time export, it is a retention and integrity property over time. You cannot retroactively make a year of access attributable if it was logged under a shared credential. You cannot recover three months of immediately-available history from a runner that rotated its disk. And you cannot prove the trail was protected from modification if it lived on the same host the service account could write to. The evidence has to have been correct, attributed, and protected on the day each access happened. Assembled at the end, it is incomplete by design.

Continuous, end-to-end evidence at the boundary

Governing machine access end to end means the record forms at the moment of access and persists outside the identity that made it. Every connection a non-human identity makes to the CDE should cross a boundary that, in one motion, identifies the account, enforces its scope, and writes a protected record on retention terms you set, not the application's log-rotation default. Do that and Requirement 10 is satisfied as a byproduct of operating, not as a project before the audit.

hoop.dev is built to be that boundary. Service accounts and other non-human identities reach the databases and services in the CDE through hoop.dev, a Layer 7 access gateway with a network-resident agent. Each identity connects as itself (Requirement 8), the gateway scopes its reach (Requirement 7), and it records every session on its own side with retention you control (Requirement 10), where the identity has no write path. Inline masking keeps full PANs from crossing to a job that only needs the last four. hoop.dev generates the evidence for PCI DSS, continuous per-identity access logs, approvals, and masked-access records, that your assessment depends on. See the getting-started docs for fronting a connection and the learn pages for how sessions are recorded and retained.

The two timelines for a service account

On the scramble timeline, the reconciliation job's February access is gone, and the team writes a compensating-control narrative explaining why. On the continuous timeline, that access was recorded in February at the boundary, under the job's own identity, masked, and protected, and it is still immediately available. When the QSA samples machine access to the CDE, you answer with records that were complete the day they were written. Same job, same data, two completely different assessments.

The difference compounds across an environment full of machine accounts. A scramble that fails for one service account fails for all of them in the same way, because they share the same broken logging path. A boundary that produces correct evidence for one produces it for every identity that connects through it, so adding a new batch job or agent does not add a new gap to close before the next assessment. Governing machine access end to end is less about any single control and more about every non-human identity sharing one access path that identifies, scopes, masks, and records by default.

It also changes who has to remember what. On the scramble timeline, the assessment depends on an engineer recalling which job used which credential and where its logs ended up. On the continuous timeline, the boundary already holds that mapping: every connection arrived under a named identity, so attribution is a property of the record rather than a reconstruction from memory. That is the practical meaning of audit-ready for non-human identities under PCI DSS, the evidence is correct, attributed, and retained without anyone assembling it after the fact.

FAQ

Does hoop.dev make our service accounts PCI DSS compliant?

No. PCI DSS compliance is assessed against your organization, and hoop.dev does not hold a PCI DSS certification. hoop.dev generates the continuous, protected access evidence for PCI DSS, per-identity logs, scoping, and masking, that your program presents to a QSA.

How does this help with Requirement 10 retention?

Because the access record is written at the boundary, outside the service account, you set its retention rather than depending on whatever a runner or application keeps. The trail accrues continuously and stays immediately available for the period PCI DSS expects.

hoop.dev is open source. To make machine access to the CDE accrue protected, per-identity evidence as it happens, start from the repository on GitHub.