Security | Threat Detection | Cyberattacks | DevSecOps | Compliance

Traditionally, engineers have relied on shared database passwords. When someone needs to run a query, they either already have standing access granted via a static credential everyone on the team knows, or someone has to scramble to create a quick workaround. Every new user, exception rule, or port forward through a bastion host becomes a “just this once” fix.

Regulators and auditors now demand immutable proof of every privileged action, attributed to an identity, across Secure Shell (SSH), Kubernetes, databases, and Remote Desktop Protocol (RDP).

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.