Segregated compute and NHI compliance: why direct access fails

At a glance

What this is: This is a compliance-focused analysis of segregated compute, with the key finding that direct user access to regulated workloads must be eliminated and replaced by brokered, auditable sessions.

Why it matters: It matters to IAM practitioners because regulated access controls now need to prove segregation, not just describe it, across NHI, privileged human access, and emerging agentic workflows.

By the numbers:

• 96% of organisations store secrets outside of secrets managers in vulnerable locations including code, config files, and CI/CD tools.
• Only 5.7% of organisations have full visibility into their service accounts.
• 90% of IT leaders say properly managing NHIs is essential for a successful zero-trust implementation.

👉 Read StrongDM's analysis of segregated compute by design for regulated access

Context

Segregated compute means a regulated user never connects directly to a sensitive workload. In practice, that shifts control from network reachability to enforced identity and session brokering, which is where many IAM and PAM programmes still struggle to produce audit-ready evidence.

The governance problem is broader than one vendor's architecture. PCI DSS, HIPAA, and FedRAMP all expect access paths to be isolated, controlled, and provable, but VPNs, jump hosts, and shared credentials often leave an accountability gap between policy intent and technical enforcement.

Key questions

Q: How should security teams enforce segregated compute for regulated workloads?

A: Security teams should place regulated resources behind a brokered access path so no user connects directly. The access layer should evaluate identity, device posture, and resource sensitivity before granting a session, then log the decision and activity as audit evidence. That makes segregation a technical control, not a policy statement.

Q: Why do VPNs and jump hosts often fail compliance tests for segregated access?

A: VPNs and jump hosts often fail because they widen network reach without proving that a user never touched the sensitive workload directly. Auditors usually need evidence of enforced separation, credential hiding, and session-level traceability. If the control cannot demonstrate those three things, it is usually too weak for regulated environments.

Q: What breaks when privileged credentials are exposed to end users?

A: When end users can see or reuse privileged credentials, secret sprawl begins immediately. Credentials are copied, cached, or reused outside the intended boundary, which destroys the assurance that access was isolated and temporary. In regulated environments, that exposure weakens both compliance posture and incident response quality.

Q: How do compliance teams prove that access was properly segregated?

A: Compliance teams need a single evidence chain that ties the user, device, resource, approval decision, and session activity together. Command logs, session replay, and immutable metadata matter because they show exactly what happened after access was granted. That is the proof auditors look for when they test segregation.

Technical breakdown

Proxy-brokered access as the segregation boundary

A proxy-based access layer turns segregation into an enforcement point instead of a promise. The user requests access, the policy engine evaluates identity, device posture, and resource sensitivity, and the proxy becomes the only entity allowed to talk to the target system. That matters because the sensitive workload never sees the user's endpoint directly. In IAM terms, this is closer to session-level mediation than network segmentation. The design also preserves evidence, because the decision, route, and session can all be logged from the same control point.

Practical implication: replace direct network reachability with a brokered control plane for regulated resources.

Secretless session delivery and ephemeral credential handling

Secretless access means the operator never sees the credential, even though the session still needs one behind the scenes. The proxy fetches or issues ephemeral credentials from a vault or internal certificate authority, injects them at the last hop, and discards them when the session ends. That reduces exposure from copied passwords, cached keys, and reused database logins. For regulated environments, the key design change is that the credential lifecycle is owned by the access layer, not by the end user or their workstation.

Practical implication: move privileged secrets behind the broker and verify that no human operator ever handles them.

Context-aware enforcement and session evidence

Segregated compute is not complete unless the system can prove who was allowed in, under what conditions, and what they did. Context-aware controls combine identity, device trust, and resource sensitivity, then write the resulting decision and activity into immutable logs, command records, or session replay. That is the difference between policy and proof. In audit terms, this closes the gap that jump hosts and VPNs often leave open, because the control point is also the evidence source.

Practical implication: require session-level audit artefacts that prove segregation, not just access approval records.

Breaches seen in the wild

• Cisco DevHub NHI breach — IntelBroker exploited exposed Cisco credentials, API tokens and keys in DevHub.
• ASP.NET machine keys RCE attack — 3,000+ exposed ASP.NET machine keys enabled remote code execution.

Read our 52 NHI Breaches Analysis report for a comprehensive view of breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

Segregated compute is now an identity problem, not just a network design problem. Once regulated workloads can only be reached through brokered sessions, the access layer becomes the control plane auditors judge. That changes the programme boundary for IAM, PAM, and compliance teams, because evidence must show that the path itself enforces separation. Practitioners should treat session brokering as a first-class governance control, not a convenience feature.

Secret distribution is the weak link segregation is meant to remove. The article's core claim is that direct credentials, shared logins, and copyable secrets undermine the whole compliance story. That aligns with the broader NHI problem space, where unmanaged secrets and unclear lifecycle controls create audit failures long before a breach occurs. Practitioners should assume that any human-visible credential path weakens segregated compute by design.

Regulated access still fails when accountability stops at the session boundary. A session log is useful only if it binds identity, device, resource, and action into one evidence chain. If those signals live in separate tools, auditors get fragments instead of proof. Practitioners should re-evaluate whether their current IAM stack can generate tamper-resistant access evidence across human and non-human actors.

Zero Trust for regulated workloads depends on whether the access model can absorb both human and non-human identities. Segregated compute gives a concrete example of that pressure: the architecture must control who or what reaches the workload, hide secrets from the operator, and preserve evidence for review. Practitioners should use this as a test of whether their Zero Trust programme is architectural or merely declarative.

From our research:

• 96% of organisations store secrets outside of secrets managers in vulnerable locations including code, config files, and CI/CD tools, according to Ultimate Guide to NHIs.
• Only 5.7% of organisations have full visibility into their service accounts, which means most environments cannot reliably prove who or what is holding privileged access.
• For lifecycle and offboarding detail, review Ultimate Guide to NHIs , Lifecycle Processes for Managing NHIs and use it to tighten revocation, rotation, and access review workflows.

What this signals

Secretless access will become a board-level proof point, not just an architecture preference. As regulated environments shift toward brokered sessions, teams will be judged on whether they can show no direct path, no exposed secrets, and no ambiguous audit trail. The control problem is increasingly about evidence quality, not access convenience, which is why many programmes will need to reconcile Zero Trust design with stronger NHI lifecycle governance.

Segregated compute exposes the hidden dependency between PAM and NHI governance. Human administrators still rely on machine credentials, certificates, and injected secrets to reach sensitive systems, so a human-only access review misses the real risk surface. Teams should expect compliance reviews to focus more on secret handling, session brokering, and offboarding of privileged machine access than on static entitlement lists.

Compliance teams should treat unmanaged secrets as the first signal that segregation is failing. With 96% of organisations storing secrets outside secrets managers, the market reality is that evidence often collapses before a breach ever occurs. The practical response is to align access architecture, secret lifecycle, and audit logging around the same control boundary.

For practitioners

• Map regulated workloads to brokered access paths Identify every production database, server, and cluster that still accepts direct user connections. Move those resources behind a proxy-controlled path so access is mediated, logged, and policy-checked before any session begins.
• Eliminate human-visible secrets from privileged workflows Replace shared passwords and copied keys with ephemeral credential injection at the access boundary. Verify that operators never see, store, or reuse the secrets used to reach regulated systems.
• Bind audit evidence to the full session chain Correlate identity, device posture, target resource, and session activity in one evidence set. Export logs and command records into your SIEM so compliance teams can reconstruct each privileged action without relying on screenshots or manual attestations.
• Use zero-trust controls to support compliance assertions Tie segregation requirements to your zero-trust policy design and access review process. Reassess whether your current control set can prove no direct connections, no exposed credentials, and complete session traceability.

Key takeaways

• Segregated compute succeeds only when the access path itself enforces separation and generates proof.
• Direct credentials, VPN-style reachability, and weak session logging are the main reasons compliance programmes fail segregation tests.
• IAM and PAM teams should treat brokered access, secret hiding, and immutable session evidence as one control stack.

Key terms

• Segregated Compute: Segregated compute is the practice of ensuring users never connect directly to sensitive workloads. Access is mediated through a controlled boundary that enforces policy, hides credentials, and produces evidence that the workload remained isolated from unmanaged connections.
• Secretless Access: Secretless access is a session pattern where the operator never sees the underlying credential. The access layer injects short-lived secrets or certificates at the last hop, reducing the chance of copying, reuse, or leakage across regulated systems.
• Session Brokering: Session brokering is the act of placing an enforcement layer between the user and the target resource. It evaluates policy before connection, routes approved traffic through a controlled proxy, and preserves logs that prove what happened during the session.
• Immutable Audit Trail: An immutable audit trail is a tamper-resistant record of access decisions and session activity. In identity programmes, it ties the actor, device, target, and action together so auditors can reconstruct privilege use without relying on manual attestations.

Deepen your knowledge

Segregated compute, session brokering, and secretless access are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are designing compliance controls for regulated workloads, it is worth exploring.

This post draws on content published by StrongDM: Segregated Compute by Design: How StrongDM Ensures Compliance. Read the original.