Could you evidence your Linux access controls to an auditor today?
The free Linux identity maturity assessment: twenty questions on the sudo rules, SSH keys, service accounts and access reviews that NIS2, DORA and the CIS Benchmarks ask you to evidence. Answer for your estate as it is today and get a level from 1 to 4, with the gaps that matter most and where to focus next. No form, no vendor pitch.
What you'll get
A maturity level (1–4) across 5 Linux identity domains, with specific gaps and prioritised next steps — no vendor pitch attached.
How to answer
Answer for your Linux environment as it is today, not as it's planned. There are no wrong answers — honesty produces the most useful output.
What we cover
Identity inventory, privilege control, access governance, service accounts & NHI — including the accounts AI agents authenticate as — and compliance & audit readiness across Linux systems.
0 of 20 answered
The foundation of Linux identity security is knowing what exists. Most organisations discover their biggest risk is simply not knowing — orphaned accounts, undocumented service users, and shared credentials that predate their current team.
How complete is your current inventory of human accounts with Linux access?
Orphaned accounts are the single most common critical finding across Linux environments. You cannot secure what you cannot see.
How quickly could you produce a complete list of every account with local login access to a given Linux server?
Audit teams and incident responders ask this question on short notice. Manual effort of more than an hour is a control gap.
Do you have visibility into accounts that exist on Linux systems but are not linked to a current employee, contractor, or service?
These orphaned or ghost accounts are the most common privilege escalation entry point and often predate current team membership.
How well do you understand group membership across Linux systems — specifically which users are in security-sensitive groups (sudo, wheel, docker, etc.)?
Over-permissive group membership is often invisible. Many privilege escalation paths exist through groups, not individual account settings.
Privilege escalation through misconfigured sudo, NOPASSWD entries, and undocumented root accounts is the most exploited Linux attack vector. Many organisations have never done a systematic review — and don't know what they'd find if they did.
How well do you know your current sudo configuration across all in-scope Linux systems?
Sudo drift is extremely common and rarely monitored. NOPASSWD entries and overly broad sudoers rules are found in almost every environment that has not been actively managed.
How do you handle NOPASSWD sudo entries (commands or users that can escalate without a password)?
NOPASSWD entries are a known critical risk — they allow privilege escalation without authentication. They are often added for convenience and never reviewed.
How does your organisation enforce the principle of least privilege for human users on Linux systems?
Broad sudo access granted "temporarily" and never reviewed is one of the most common root causes of excessive privilege exposure.
Can you tell, right now, which human users can run commands as root on a specific production Linux server — without physically logging into that server to check?
This is a basic audit question. Being unable to answer it without manual intervention means your privilege visibility is reactive, not proactive.
SSH keys that outlive the people who created them, group memberships that expand over time, and manual provisioning processes with no formal deprovisioning — these are governance failures more than technical ones, and they compound every year.
What happens to Linux access when an employee or contractor leaves the organisation?
Manual offboarding that depends on IT ticket completion is a control gap. Leavers with retained access represent an ongoing risk that grows with employee turnover.
How do you manage SSH authorised keys — specifically, do you know what keys exist, who they belong to, and which are still in use?
SSH keys are effectively long-lived passwords. Keys tied to former employees, rotated credentials, or unknown origins are a persistent, unaudited risk vector.
Do you run formal access reviews (recertification) on Linux system access — where managers or system owners confirm each user's access is still required?
Access reviews are a requirement of ISO 27001, SOC 2, NIS2, and most major frameworks. Completing these manually or skipping Linux systems is a compliance gap.
How quickly does new Linux access get provisioned — and is there an approval workflow before it is granted?
Ad-hoc provisioning without approval creates undocumented access and makes access reviews meaningless. A consistent provisioning process is a prerequisite for mature governance.
Service accounts, automation users, and pipeline credentials are the fastest-growing and least-managed identity category on Linux. They often hold disproportionate privilege, are rarely rotated, and exist outside normal HR-linked identity lifecycle processes.
Do you have a complete inventory of service accounts and non-human identities (automation users, pipeline credentials, application accounts) with Linux access?
Service accounts and NHI are the fastest-growing and least-managed identity category. They are rarely linked to HR records and often exist outside normal lifecycle processes.
How do you manage the credentials (passwords, keys, tokens) used by service accounts on Linux systems?
Service account credentials that are static, never rotated, or shared across systems are a critical vulnerability — and attackers specifically target them for lateral movement.
Are service accounts on your Linux systems limited to the minimum privilege needed for their function — and has this been reviewed recently?
Service account privilege creep is extremely common and high impact. A compromised overprivileged service account is often the stepping stone to full environment compromise.
Do you know which CI/CD pipelines, automation tools, or third-party integrations have SSH or sudo access to your Linux systems?
Pipeline credentials and automation access are often configured once and forgotten. They represent a significant and underappreciated supply chain risk surface.
NIS2, DORA, ISO 27001, PCI DSS, and SOC 2 all require evidence of privileged access controls. Many security teams can describe their controls verbally, but cannot produce exportable, audit-ready documentation on demand — which is what auditors actually require.
If your auditor asked today for a report of all privileged Linux accounts and their access levels, how quickly could you produce it?
This is a specific, common audit requirement under ISO 27001, SOC 2, NIS2, and PCI DSS. Being unable to produce it on demand is a findings risk and a sign of control immaturity.
Do you have documented evidence of access reviews, privilege certifications, or user entitlement audits for your Linux systems — evidence that an auditor could examine?
Verbal descriptions of controls are not audit evidence. Auditors need records — timestamps, reviewer names, access decisions. Without these, controls are considered informal.
Which regulatory or compliance frameworks apply to your Linux environment and how confident are you in your Linux identity controls meeting those requirements?
NIS2 (Article 21), DORA, PCI DSS (Req 7, 8), ISO 27001:2022 (A.5.15, A.8.2), and SOC 2 (CC6) all have specific identity and access management requirements that cover Linux systems.
When was the last time your Linux identity and access controls were independently reviewed — by an external party, red team, or internal audit?
Self-assessment is valuable but has limits. Independent review surfaces blind spots and provides the credibility that internal documentation alone cannot.