Why LinuxGuard
Your existing stack covers everything it was designed to cover. Linux identity is what's left.
Your existing security stack watches endpoints, logs, and the directory. The identity layer that actually governs your Linux estate lives somewhere none of them can see.
Sudo rules, SSH keys, local and service accounts, PAM — the artefacts that decide who can do what on your servers sit below the directory and outside the log stream. LinuxGuard makes every one of them known, governed, and continuously assured.
Linux Identity Security Posture
Where LinuxGuard sits — the identity layer beneath your existing stack.
Linux identity risk is not an endpoint problem or a directory problem — it is an OS-level posture problem, and it is not new. Years of sudo rules, SSH keys, local and service accounts have built paths to root on the hosts themselves, and nothing in the standard stack — SIEM, EDR or cloud IAM — maps them. What has changed is how fast those paths get used: automation and agents in CI/CD, vendor tooling and developers' hands authenticate as service accounts and use whatever reach they inherit. DORA and NIS2 already ask for demonstrable control over privileged access. LinuxGuard is the control plane for that layer: continuous posture, and response when something changes.
Identity Security Posture Management (ISPM) for the Linux estate — continuous posture, not a point-in-time scan.
KuppingerCole Identity Fabric — infrastructure layer complete — Linux OS identities are an explicit Fabric component; LinuxGuard closes the gap most IAM stacks leave open.
The OpenAI / Hugging Face incident (July 2026) shows the pattern. Autonomous agents got code execution inside production Kubernetes pods, then used the service-account tokens they found there, privileged pods for node-level root, static database credentials and stolen automation keys to go further. None of the techniques was new. Every path existed before the agents arrived — they were simply chained faster. Sources: Cloud Security Alliance research note and OpenAI's incident post, both 2026. Our own account: what the incident means for Linux identity.
Want to see where your own estate sits? Take the Linux Identity Maturity Assessment — 20 questions, an instant score, no form.
Why LinuxGuard?
Compared against the three ways this work gets done today — by hand, with a vulnerability scanner, or with a PAM platform — and what each one leaves uncovered on Linux.
Complete inventory of all Linux users, groups, service accounts
- Manual / Internal Effort
- Possible but slow; server-by-server
- Vulnerability Scanner
- Not designed for this
- PAM Platform
- Managed accounts only; not full estate
- LinuxGuard
- Continuous, always-current inventory
Sudo rule analysis and NOPASSWD risk identification
- Manual / Internal Effort
- Requires scripting skill; inconsistent
- Vulnerability Scanner
- Out of scope
- PAM Platform
- Not a PAM function
- LinuxGuard
- Complete sudoers parsing and risk scoring
SSH key audit (shared, unrotated, orphaned)
- Manual / Internal Effort
- Manual; easy to miss cross-server relationships
- Vulnerability Scanner
- Out of scope
- PAM Platform
- Managed vaulted keys only
- LinuxGuard
- Cross-fleet SSH key mapping
Privilege path visibility across accounts, groups and sudo rules
- Manual / Internal Effort
- Requires red-team skill
- Vulnerability Scanner
- CVEs only; no path analysis
- PAM Platform
- Out of scope
- LinuxGuard
- Identity graph with click-to-highlight privilege paths
Compliance evidence mapped to NIS2/DORA/CIS/SOC 2
- Manual / Internal Effort
- Requires framework mapping expertise
- Vulnerability Scanner
- Raw scan output; not mapped
- PAM Platform
- Session logs; not identity posture
- LinuxGuard
- Structured, auditor-ready, control-mapped
Board/auditor-ready report
- Manual / Internal Effort
- Spreadsheet + screenshots
- Vulnerability Scanner
- Technical scan output
- PAM Platform
- Session management reports
- LinuxGuard
- Executive and technical report included
Continuous monitoring (post-pilot drift detection)
- Manual / Internal Effort
- Requires ongoing internal resource
- Vulnerability Scanner
- Scheduled scans only
- PAM Platform
- Session monitoring only
- LinuxGuard
- Near-real-time drift against an approved baseline
Fixed scope and fixed cost
- Manual / Internal Effort
- Variable; depends on estate size and skill
- Vulnerability Scanner
- Tool cost + internal time
- PAM Platform
- High licensing + professional services
- LinuxGuard
- Fixed-fee pilot — €24,000
Time to actionable results
- Manual / Internal Effort
- Weeks to months
- Vulnerability Scanner
- Fast scan, slow remediation
- PAM Platform
- Months to deploy and baseline
- LinuxGuard
- Within a week, then continuously updated
| What's Needed | Manual/Internal Effort | Vulnerability Scanner | PAM Platform | LinuxGuard |
|---|---|---|---|---|
| Complete inventory of all Linux users, groups, service accounts | Possible but slow; server-by-server | Not designed for this | Managed accounts only; not full estate | Continuous, always-current inventory |
| Sudo rule analysis and NOPASSWD risk identification | Requires scripting skill; inconsistent | Out of scope | Not a PAM function | Complete sudoers parsing and risk scoring |
| SSH key audit (shared, unrotated, orphaned) | Manual; easy to miss cross-server relationships | Out of scope | Managed vaulted keys only | Cross-fleet SSH key mapping |
| Privilege path visibility across accounts, groups and sudo rules | Requires red-team skill | CVEs only; no path analysis | Out of scope | Identity graph with click-to-highlight privilege paths |
| Compliance evidence mapped to NIS2/DORA/CIS/SOC 2 | Requires framework mapping expertise | Raw scan output; not mapped | Session logs; not identity posture | Structured, auditor-ready, control-mapped |
| Board/auditor-ready report | Spreadsheet + screenshots | Technical scan output | Session management reports | Executive and technical report included |
| Continuous monitoring (post-pilot drift detection) | Requires ongoing internal resource | Scheduled scans only | Session monitoring only | Near-real-time drift against an approved baseline |
| Fixed scope and fixed cost | Variable; depends on estate size and skill | Tool cost + internal time | High licensing + professional services | Fixed-fee pilot — €24,000 |
| Time to actionable results | Weeks to months | Fast scan, slow remediation | Months to deploy and baseline | Within a week, then continuously updated |
But doesn't my existing stack already cover this?
But my IGA tool already covers Linux…
IGA governs the directory plane — it manages joiner/mover/leaver workflows against AD, LDAP, or your HR system, and it does that well. What it cannot do is read the host. Local accounts, service accounts, sudoers drop-ins, authorized_keys files, and PAM module chains are not provisioned through the directory; they exist below it, on the servers themselves. IGA will never flag a NOPASSWD sudo rule or an orphaned local account, because those artefacts were never part of the workflow it manages. It knows the account exists; it does not know what that account can do once it resolves on a Linux host.
But my SIEM already covers Linux…
A SIEM answers the question of who logged in, and when. That is a different question from what can each identity actually do. Standing privilege — the sudo rules, SSH key relationships, and escalation paths that define your real attack surface — is configuration state at rest. It generates no events until it is abused, and a log stream cannot reconstruct it after the fact, no matter how far back you retain. LinuxGuard maps that state before any event occurs.
But my EDR/XDR already covers Linux…
EDR and XDR are excellent at what they were built for: detecting anomalous behaviour once a process runs. The problem is that Linux identity risk is not a behavioural event — it is a configuration fact. Which service accounts can escalate to root, which SSH keys are shared across ten servers, which sudoers rules grant passwordless access to the entire fleet: none of that is a process. It is the posture that determines what an attacker can do the moment they land. EDR does not see it — it covers the process, and it does not know a NOPASSWD entry from a normal one.
But we're already running a PAM platform…
PAM platforms record and control privileged sessions — they are the gate through which approved sessions are meant to pass. But they only govern what flows through them. Local accounts, service accounts configured to bypass PAM, SSH keys that authenticate directly to the host, and sudo rules that escalate without a brokered session all operate outside that perimeter. LinuxGuard maps the identity posture that exists on the host regardless of how access was obtained — so you can see what your PAM platform does not broker, and close those paths. It sits under your PAM platform and feeds its findings into it; it does not replace the session broker. For a platform-by-platform view, see how CyberArk and BeyondTrust compare with Teleport, FreeIPA, Delinea, StrongDM, HashiCorp and Okta Privileged Access on Linux.
We run immutable infrastructure and containers. Nobody logs into our hosts.
Nobody logs in — the workloads do, as identities. Kubernetes nodes are still Linux hosts, privileged DaemonSets run as root on them, and many container images run as root by default. Immutable infrastructure bakes privilege in once and copies it to every replica. That is also why session-based host PAM struggles here: when nobody logs in, there is no session to broker. The OpenAI / Hugging Face incident ran through exactly this kind of estate. LinuxGuard runs on each node as a DaemonSet and maps the node's own identity layer.
We already use Teleport.
Teleport governs the access it brokers and can surface unmanaged keys in that estate — how Teleport and LinuxGuard compare sets the two side by side. LinuxGuard maps what every identity can do on the host once it is there — sudo rules, local and service accounts, PAM chains, paths to root — however it arrived. They answer different questions and work side by side.
We're consolidating on an identity or NHI platform.
Identity and NHI platforms are built around cloud, SaaS, secrets and directory identity. What an identity can do on the Linux host itself is a layer beneath them. LinuxGuard maps that layer and feeds its findings into the platform you choose.
But we're in the cloud — does this still apply?
Cloud infrastructure runs on Linux. Every EC2 instance and every managed Kubernetes node has an OS-level identity layer beneath the cloud IAM controls your team manages from the console. Cloud IAM governs the AWS, Azure, or GCP plane; it does not govern the local accounts, sudoers files, SSH keys, and PAM configuration on the instances themselves. The Linux identity layer follows your hosts wherever they run — on-premises, cloud, or hybrid, including the nodes under your Kubernetes clusters.
But my Cloud IAM / Active Directory already covers Linux…
Cloud IAM and Active Directory govern the identity and console plane — authentication at the directory level. Linux identity lives one layer down, on the hosts themselves: local users, groups, sudoers files, SSH keys, and PAM configuration all sit below the directory boundary and persist independently of it. Disabling a directory account does not remove a local account or revoke an authorized_keys entry. What happens on the server after login is governed entirely by artefacts the directory has never seen.
But we're not running AI agents…
Then the paths to root on your hosts are the same — they are just used more slowly. The problem LinuxGuard addresses is the access that has built up over years. Agents only change how quickly it gets used. Your vendors, CI/CD and developers are likely running agents already, and on a Linux host they appear as service accounts.
But we run periodic manual reviews…
Manual reviews find the state of a fraction of the fleet at a single point in time — and that state is already ageing by the time the report is written. Privilege creep does not wait for the next review cycle: a developer gets added to sudoers for one deployment and is never removed; a service account granted access for a migration outlives the project by months; an SSH key remains in authorized_keys long after the person who owned it has left. Continuous assurance sees every change, across every host, as it happens — not a quarterly snapshot of a subset.
But my vulnerability scanner already flags this…
Vulnerability scanners look for known software weaknesses: unpatched packages, exposed services, missing patches against published CVEs. Linux identity risk is none of those things. A NOPASSWD sudo rule, an unrotated SSH key shared across fifteen servers, or a service account with direct root access is a configuration and relationship problem — it carries no CVE, it appears on no patch list, and no scanner will ever surface it. It is invisible to that class of tool by design.
But our Linux estate is small — is it still a problem?
Fleet size determines the scale of the exposure, not its existence. A single server with an orphaned NOPASSWD sudo rule, an unrotated shared SSH key, or a service account running as root carries the same privilege risk as the same misconfiguration across a thousand servers. The difference is that a small estate is often less reviewed precisely because it is considered low risk. LinuxGuard gives you the same continuous visibility regardless of scale — because a blind spot is a blind spot whether it appears once or a thousand times.
But our Linux estate isn't all Ubuntu and Red Hat…
Most estates are not, and the hosts that fall outside the mainstream are usually the ones no inventory covers. The LinuxGuard agent is packaged for Debian, RPM and Alpine hosts, built for amd64, arm64, armhf and riscv64, and runs under systemd, OpenRC, runit or s6. The Alpine hosts, the ARM edge devices and the non-systemd hosts are therefore inside the estate you can see, not exceptions listed in a footnote — their accounts, groups, sudo rules, SSH keys and PAM configuration are collected and scored wherever the agent runs.
But every security dashboard looks complete on day one…
Most do, and that is the problem: a console that renders an unmeasured signal as a zero turns an unknown into a false all-clear, which is worse than showing nothing. LinuxGuard separates the two. Where something has not been collected — a host that has not reported yet, a check that has not run — the interface says so rather than displaying a zero or a green tick. Some panels therefore read as incomplete at the start of a deployment. That is deliberate: what you are looking at is what has actually been measured on your estate.
But compliance auditors haven't flagged this…
Auditors assess against the controls they are scoped to test, and Linux OS-level identity is rarely in scope for a standard IGA, access management, or cloud security review. That absence from the audit scope does not mean the risk is absent — it means it has not been looked at. Regulators under NIS2, DORA, and equivalent frameworks are increasingly explicit that privileged access governance must extend to the full identity surface, not just directory-provisioned accounts. If your Linux estate is not in scope today, that is unlikely to remain the case.
See what your stack has been missing.
Bring your Linux estate into view — every account, key, sudo rule, and PAM path, known and continuously assured. Book a demo and we'll show you the identity layer your existing tools can't.