Notifications
Clear all
Topic starter
07/06/2026 9:27 pm
TL;DR: Segregated compute requires no direct user connection to sensitive workloads, with every session brokered, credential-hidden, and logged for PCI DSS, HIPAA, and FedRAMP audits, according to StrongDM. That architecture matters because shared credentials, VPN-style access, and jump hosts still leave identity governance gaps that compliance teams must prove away.
NHIMG editorial — based on content published by StrongDM: Segregated Compute by Design: How StrongDM Ensures Compliance
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.
Questions worth separating out
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.
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.
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.
Practitioner guidance
- Map regulated workloads to brokered access paths Identify every production database, server, and cluster that still accepts direct user connections.
- Eliminate human-visible secrets from privileged workflows Replace shared passwords and copied keys with ephemeral credential injection at the access boundary.
- Bind audit evidence to the full session chain Correlate identity, device posture, target resource, and session activity in one evidence set.
What's in the full article
StrongDM's full blog covers the operational detail this post intentionally leaves for the source:
- Step-by-step proxy architecture for SSH, RDP, database, and Kubernetes access paths.
- Detailed mappings to PCI DSS, HIPAA, and FedRAMP control expectations and audit evidence.
- Examples of command logging, session replay, and immutable log export patterns.
- How contextual policy decisions are enforced at session start across identity, device, and resource risk.
👉 Read StrongDM's analysis of segregated compute by design for regulated access →
Segregated compute for regulated access: are your controls auditable?
Explore further
08/06/2026 9:25 am
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.
A few things that frame the scale:
- 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.
A question worth separating out:
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.
👉 Read our full editorial: Segregated compute and NHI compliance: why direct access fails
