Early in my career, I broke a client’s production system in the worst possible way.
It was a last‑minute fix before a big presentation. I had access to the Linux server, I was under pressure, and I made a single recursive permissions change from root. It felt harmless in the moment — a quick way to “just make it work” before the meeting. Twenty minutes later, sitting in the middle of the client presentation, I watched their website die in slow motion as cache TTLs expired and processes started failing, one by one. And there is a special kind of pain in realising that you are the cause of an outage you can’t stop, in front of the people who trusted you.
The truth is brutal: I was allowed on that server, but I did something I should never have been technically able to do.
That experience never left me. At the time it was an embarrassing war story. In hindsight, it was a perfect microcosm of the industry’s real problem: not the absence of tools, but the absence of meaningful control. We do not lack access. We lack guardrails.
The Pattern I Kept Seeing Everywhere
Over the next two decades, across Mastercard, EY, UBS, the UK Government, and many more, I saw the same structural weakness repeated at scale.
On paper, the security story always looked impressive: enterprise IAM, SSO, PAM, SIEM, GRC dashboards, regulatory heat maps. The decks were immaculate. The roadmaps were multi‑year. The spend was very real.
But underneath all of that, the operational reality was always the same:
- Nobody could give a precise, current answer to a simple question: “Who can do what on every Linux server we run?”
- Offboarding workflows were beautifully automated for SaaS and AD — and almost completely blind to SSH keys and local Linux accounts.
- “Temporary” access and “temporary” integration servers quietly became permanent, accumulating privileges that were never revisited.
The statistics most organisations like to quote about “average breach costs” and “time to detect” are not abstract to me. They are the direct consequence of this blindness. IBM’s recent data shows credential‑based breaches still take around nine months to contain end‑to‑end, even as overall detection times improve — a gap driven largely by over‑privileged access and unmanaged credentials in infrastructure layers nobody is watching closely enough.
And that infrastructure is overwhelmingly Linux.
Linux runs the majority of web‑facing servers, critical workloads, and backend services in modern enterprises. Yet identity and governance practices still orbit around Windows and SaaS, as if the systems that actually move money, control manufacturing, or run payment stacks somehow sit outside the identity problem.
They don’t. They are the identity problem.
The Offboarding Illusion
The second pattern I kept seeing was offboarding theatre.
From a distance, it looks solid: HR triggers a workflow, SSO accounts are disabled, VPN access is revoked, AD accounts are deprovisioned, licences reclaimed. The dashboard says “complete.” The CISO breathes out.
Up close, it is very different. Multiple industry studies over the last decade show:
- Only a minority of organisations can confidently say all access is revoked within 24 hours when someone leaves.
- A very large majority of former employees retain access to at least one system after departure — not because anyone intended it, but because credentials live in more places than the IAM stack is aware of.
What those numbers hide is where the residual access actually lives: long‑lived SSH keys on Linux servers, unreviewed sudo rules, scripts and CI/CD jobs still authenticating with keys generated by engineers who left years ago, and shared service accounts that no one “really owns” anymore.
This is the dangerous middle ground between my early‑career mistake and today’s reality. Back then, I had root and made a bad decision. Today, a former colleague may still effectively have root — not through an active HR record, but through a forgotten key in an authorized_keys file, or a service account no one dared touch because it “runs something important.”
We are very good at terminating people in IAM. We are still terrible at terminating their power in Linux.
Why “We Have PAM and Directory Auth” Is Not an Answer
In almost every organisation I visit, there is a familiar line:
“We’re covered. We have directory authentication and PAM.”
What that really means is:
“We can stop unauthenticated people logging in. After that, we hope for the best.”
Modern privilege escalation bugs on Linux — like the recent snapd/systemd timing issue on Ubuntu — are a perfect illustration of the gap. They do not require exotic chains of exploits or 47 preconditions. They require one thing: a local account with enough access to be present on the box.
Once that foothold exists, all the beautiful authentication plumbing is behind you. The only thing that matters is what that account can do locally:
- Is sudo locked down or wide open?
- Are there fragile “fix it fast” permissions still in place from a previous incident?
- Does this account own keys that are trusted on other systems?
My early recursive permission mistake was a manual own goal. Today, the same lack of guardrails can be exploited deliberately — and at scale. The tooling that tells you “user X authenticated” is not the same thing as tooling that can tell you “user X (or the process acting for them) can perform action Y on host Z, and here is how long that has been true.”
We have spent two decades mastering the former. We have barely started on the latter.
Agentic Automation: When Technical Debt Becomes a Blast Radius
For years, organisations survived with this technical debt because most damage spread at human speed. A bad action by one admin, on one box, created pain — but the blast radius was, to some extent, bounded by time and manual effort.
Agentic automation changes that equation completely.
We are now wiring autonomous agents into the same Linux estates that already have:
- Poorly baselined sudo,
- Unknown SSH key inventories,
- Long‑lived service accounts with broad privileges,
- And weak separation between “temporary” integration environments and production.
Once agents can act on behalf of humans — invoking scripts, logging into systems, deploying changes — any over‑privilege becomes multiplicative. A compromise is no longer “one admin doing something they shouldn’t.” It is “a non‑human actor tirelessly exercising every permission it inherited, across every system it can see, at machine speed.”
In this world, the kind of mistake I made early in my career is no longer an embarrassing outage — it is a potential systemic event. And incidents that would once have been “moderate” in scope can now propagate through automation, supply chains, and intertwined IT/OT environments in ways we are not structurally prepared to contain.
The uncomfortable truth is that most organisations are wiring AI‑driven automation on top of identity and access foundations that were never designed to withstand it.
IT/OT: Where “Password on the Whiteboard” Meets Zero Trust
Nowhere is this more obvious — and more dangerous — than at the intersection of IT and OT.
In the OT world, “admin forever” isn’t a theoretical risk; it has been the operating model for decades. Production SCADA systems that cannot be rebooted without halting factories. Service accounts from vendors that no longer exist. Shared credentials on whiteboards because “at 2 AM, we don’t have time for process.”
IT and OT are converging whether we like it or not:
factories are talking to ERP, building management is in the cloud, industrial sensors tunnel back into data lakes, and remote access bridges worlds that used to be air‑gapped.
The hinge of that convergence is almost always the same:
Linux and Unix jump hosts, historians, and “temporary” integration servers that were meant to be short‑lived and are now silently business‑critical.
That’s where:
- Root and sudo ALL=(ALL) NOPASSWD:ALL quietly live.
- Seventeen orphaned SSH keys still work because no one knows which ones are “safe” to remove.
- The admin who left three years ago still has effective access, even though their HR record was closed long ago.
When a compliance framework looks at this world, it does not see “quirks of OT culture.” It sees uncontrolled privilege paths deep inside critical infrastructure. And as regulations evolve, they are starting to call that out explicitly.
Compliance: Not a Checklist, but a Mirror
Regimes like DORA and NIS2 are often framed as bureaucratic obstacles. In reality, they are a mirror held up to the exact problems I have been describing.
DORA’s Register of Information and ICT risk requirements force financial institutions to prove they understand all critical systems, their dependencies, and who has privileged access to them — not just in third‑party contracts, but inside their own estate. Early surveys already show a painful gap between “we filed something on time” and “we can actually evidence least privilege and controlled access on the systems that run our core services.”
When a regulator or auditor walks in and asks:
- “Show us who has privileged access to the Linux servers running your payment processing stack.”
- “Show us how you ensure ex‑contractors cannot still pivot into critical systems via old keys or jump hosts.”
— you can’t answer with a Windows access review from 2023 and a hope that nobody asks follow‑up questions.
The organisations that treat these regulations as one‑off fires to fight will keep living in the 11:59 world: scrambling before every audit, patching over symptoms, and hoping nothing big breaks in between. The organisations that treat them as an architectural mandate — a requirement to actually understand and control privilege end‑to‑end — will build something far more valuable than compliance.
They will build resilience.
Why I Built LinuxGuard
LinuxGuard is my answer to everything I’ve just described — and to that younger version of myself, sitting in a client meeting watching a production system fall apart because nobody had put guardrails between “allowed on the server” and “able to do irreversible damage.”
I built LinuxGuard because:
- Linux is where most of the world’s real work actually runs, but it has been structurally under‑governed from an identity and privilege standpoint.
- Traditional IAM and PAM strategies stop at the login prompt; they do not tell you, continuously and precisely, what any given identity can actually do on any given Linux host.
- The combination of accumulated technical debt, agentic automation, and IT/OT convergence has turned unmanaged Linux privilege from a nuisance into a systemic risk.
LinuxGuard’s job is simple, and deliberately unglamorous:
- Make every Linux and Unix account, key, sudo rule, and privilege path boringly visible.
- Continuously baseline what “normal” access looks like and highlight drift before it becomes incident fodder.
- Give security, operations, and risk teams the ability to move from “admin forever” to “admin just long enough” — without taking the plant down or breaking the payment stack.
- Turn regulatory demands (DORA, NIS2, and whatever follows) into something you can evidence with data, not PowerPoint.
I didn’t build LinuxGuard because the world needed another logo on a security landscape slide. I built it because after twenty years of watching the same movie — from my own early mistakes to systemic failures in critical environments — it was clear that nobody was going to fix Linux identity and privilege for us.
We can’t afford to keep treating Linux as the system IAM forgot.
If the last‑minute change I made early in my career happened today, in a fully automated, agent‑driven, tightly coupled IT/OT environment, it wouldn’t just take down a website in a meeting. It could ripple through pipelines, downstream systems, and physical infrastructure before anyone realised what had happened.
LinuxGuard exists so that story doesn’t keep repeating — with exponentially higher stakes.