Security | Threat Detection | Cyberattacks | DevSecOps | Compliance

On workload identity, a spec the industry has already started building around, and what the next layer looks like. I don't have a better answer than SPIFFE (Secure Production Identity Framework for Everyone) for workload identity, and that's where I want to start, because what follows is going to sound like I do.

A device in your fleet encounters an issue. You try to SSH in only to discover that the IP changed overnight, the customer's firewall blocks inbound connections, and the VPN they set up six months ago stopped working when the device switched from Wi-Fi to cellular. The next several hours disappear into a Slack thread with the customer's IT team trying to get a port opened. Every engineer who has shipped hardware into a customer's environment has a version of this story.

Organizations pursuing CMMC Level 2 readiness are discovering that the hardest challenges sit not in the controls themselves, but in operationalizing them consistently across administrative access, identity enforcement, and audit visibility.

Our previous post, How to Secure Microservices with SPIFFE and Istio, showed how to secure Kubernetes microservices using Istio policy and SPIFFE identities, with Teleport issuing the identities that the mesh trusts. The question teams face next is: How do you extend that identity-driven security model to workloads outside Kubernetes — such as VMs, edge gateways, and legacy services — without creating a massive certificate-management project?

Tatu Ylonen, the inventor of the SSH protocol, has long warned that a single stolen SSH key "can in many cases lead to compromise of the entire server environment." But in the bare-metal and private cloud infrastructure of high-frequency or quantitative trading firms, privileged access to trading infrastructure often depends on shared or static credentials like SSH keys or hardcoded API tokens.

Most multi-site infrastructure teams manage access and audit logging site by site, using stacks that have been built up over time through different tools, different owners, and thousands of static credentials or standing admin privileges. This makes org-wide auditability nearly impossible to produce on demand, and adds complexity to regional compliance requirements.

Whether it’s vendors diagnosing GPU driver failures or network technicians troubleshooting switch configurations, organizations are often ready to do whatever it takes to get their infrastructure back to normal. For some, that may mean defaulting to the fastest access path available for third-party access, such as shared SSH keys, VPN credentials, or screen-sharing sessions.

Most Secure Shell (SSH) hardening advice starts and ends with two changes: move off port 22 or disable root login. Both are easy to implement, widely recommended — and almost entirely misunderstood.

Organizations that operate servers across data centers, cloud accounts, and colocated environments face a problem that grows with each site they add: identity fragmentation. If an engineer needs access to infrastructure in ten locations, it's highly likely that the identity and access systems governing those locations exist in ten separate configurations. Each new site or cloud deployment also creates thousands of new credentials, adding new paths and additional attack vectors.