Security | Threat Detection | Cyberattacks | DevSecOps | Compliance

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.

→ What DORA assessors actually evaluate → How DORA controls map to specific evidence requirements → Common evidence gaps that can interfere with audits → The evidence challenges of agentic AI → The full blueprint for DORA compliance now and in the future The Digital Operational Resilience Act (DORA), otherwise known as Regulation (EU) 2022/2554, represents a fundamental shift in how financial institutions must show their compliance.

As a solutions architect, building out customer demo environments is part of the job. I regularly spin up lab scenarios to support evaluations and proof-of-concept work — and if you've done this before, you know it can eat up days of your life. So when I recently decided to refresh my homelab and migrate to Proxmox, I saw it as the perfect opportunity to put AI-assisted infrastructure automation to the test. The goal?

Accessing modern infrastructure requires more than a network-level foothold. As services spread across clouds, clusters, and regions, the question of who can reach what stops being a network question and becomes an identity question. Reverse proxies are the component that answers it. A reverse proxy sits between clients and backend services, validating identity and enforcing authorization on every inbound request before any application is touched.

AI agents are likely already running inside your infrastructure. They triage alerts, remediate incidents, provision resources, and make decisions without waiting for a human to approve each step. For teams aligned to NIST’s Cybersecurity Framework (CSF) 2.0, this creates a problem: the framework assumes human actors, human-speed decisions, and human-readable audit trails. Autonomous systems break all three assumptions. The good news is that CSF 2.0 was designed to be adapted.