Security | Threat Detection | Cyberattacks | DevSecOps | Compliance

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.

→ Audit your AI systems against EU AI Act requirements now — validate Annex IV technical documentation, logging, and data governance. The initial August 2025 compliance date has passed, and full penalties begin in August 2026. → Build a continuous compliance evidence chain — document risk management across the full lifecycle (design, development, deployment, and post-market monitoring).

My first introduction to UNIX remote access was via telnet and rsh protocols in college, which was the standard method at the time. But I soon started reading articles about how easy it was for someone to sniff the network and capture passwords since they were being transmitted in plaintext. On the shared network segments common to university campuses and early enterprise environments, the tools to intercept traffic were freely available, well-documented, and required very little skill to use.