When teams achieve ISO 27001 compliance for non‑human identities, every automated service interaction becomes traceable, scoped to the minimum required permissions, and backed by immutable evidence that auditors can verify.
What ISO 27001 expects for non‑human identities
The standard requires teams to treat service accounts, CI/CD tokens and other machine identities as assets that must be protected with the same rigor as human credentials. Control objectives require:
- Clear assignment of ownership and purpose for each credential.
- Documentation of who or what may use the credential.
- Logging of every access attempt, successful or denied.
- Evidence that privileged actions receive review and, when appropriate, approval.
- Protection of sensitive data returned by the service, especially when that data is logged or stored.
Auditors look for records that show a request originated from a known service identity, that the request was evaluated against a policy, and that the outcome – success, failure or redaction – was captured.
Why traditional approaches fall short
Most teams grant service accounts broad, standing permissions and store static keys in configuration files or secret stores. The typical flow looks like this:
- An automation script reads a long‑lived credential from a vault.
- The script connects directly to the target system – a database, a Kubernetes API, an SSH host – using that credential.
- The connection proceeds without any intermediate check, and the target trusts the credential implicitly.
- Only the target’s own logging may capture the activity, and those logs often lack the context needed for ISO 27001 evidence, such as the originating service name or the policy that justified the access.
This model satisfies the “who can start” part of ISO 27001 because the identity is known, but it leaves enforcement and evidence collection entirely to the target. If the target mis‑configures itself, logs become incomplete, or a credential over‑privileges, the organization cannot prove compliance.
How hoop.dev provides the required control plane
hoop.dev inserts a Layer 7 gateway between the non‑human identity and the target resource. The gateway performs three essential functions that map directly to ISO 27001 evidence requirements:
- Just‑in‑time authorization. When a service presents an OIDC or SAML token, hoop.dev validates the token, extracts group membership and evaluates a policy before the request reaches the target. If the policy requires human approval, hoop.dev routes the request to an approver and proceeds only after explicit consent.
- Inline data masking. hoop.dev filters responses that contain sensitive fields in real time. The gateway records the original payload and the masked version, giving auditors proof that data protection controls were applied.
- Session recording and audit. hoop.dev logs every command, query or API call with the service identity, timestamp and decision outcome. hoop.dev records each session and provides an audit trail that the target cannot modify.
Because hoop.dev sits in the data path, the gateway creates the enforcement outcomes. Removing hoop.dev would revert the system to the insecure direct‑connect model described above.
Putting it together for ISO 27001 evidence
To satisfy the standard, an organization should combine the following steps:
- Define service‑account ownership. Register each non‑human identity in the identity provider and assign it to a responsible team.
- Scope permissions to the minimum needed. Configure hoop.dev policies that grant just enough rights for each workflow.
- Require just‑in‑time approval for privileged actions. Use hoop.dev’s approval workflow for any command that modifies configuration or accesses high‑value data.
- Enable inline masking for sensitive fields. Identify columns, headers or payload attributes that must never appear in clear‑text logs and let hoop.dev redact them automatically.
- Collect immutable audit records. Export hoop.dev’s session logs to your preferred log archive; the logs include the service identity, policy decision, and any redaction performed.
- Review and retain evidence. Align log retention with ISO 27001’s documentation requirements and make the logs available for auditor inspection.
When these pieces are in place, auditors can trace a request from the originating service token, through the policy decision, to the final outcome, and see that any sensitive data was protected. That end‑to‑end visibility is exactly what ISO 27001 expects for non‑human identities.
Getting started with hoop.dev is straightforward. The official getting‑started guide walks you through deploying the gateway, registering a service account and defining a simple policy. For deeper insight into masking, approval and audit features, explore the learn section of the documentation.
FAQ
Does hoop.dev replace my existing secret management solution?
No. hoop.dev consumes the credentials you already store, but it never exposes them to the calling service. It adds a verification and control layer on top of your secret store.
Can I use hoop.dev with any OIDC provider?
Yes. hoop.dev acts as a relying party and accepts tokens from Okta, Azure AD, Google Workspace and other compliant providers.
How long are the audit logs retained?
Retention is configurable; you can set the retention period to meet your ISO 27001 requirements.
Explore the open‑source repository on GitHub to see the implementation details and contribute: github.com/hoophq/hoop.
