The tools you already run weren't built for Linux identity

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.

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.

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.

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.

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.

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.

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.

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.

Cloud infrastructure runs on Linux. Every EC2 instance, every containerised workload, 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 workloads wherever they run — on-premises, cloud, or hybrid.

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.