JIT sudo without CyberArk

Anyone who has gone through a CyberArk procurement cycle remembers two things. The first is the price: enterprise PAM deployments for a few hundred Linux hosts routinely come in between $100,000 and $400,000 in year one, depending on modules, with year-two renewals not much smaller. The second is the deployment time: six to nine months is normal, twelve months is common, and the "rollout team" line item in the quote is usually larger than the licence itself.

For a financial services company with mainframe accounts, password-rotation requirements on Windows service accounts, and a regulator who specifically names CyberArk in their guidance, that price is sometimes justified. For a 30-person Linux-shop SaaS that needs auditable sudo for SOC 2, it almost never is. Yet the second team frequently ends up evaluating CyberArk because PAM as a category is dominated by enterprise vendors and the alternatives are not well-known.

This article is the alternative. It describes JIT (just-in-time) sudo with capability tokens — a pattern that covers privileged-access auditing for Linux fleets at a fraction of the cost and complexity. It is honest about what CyberArk does that this pattern does not.

What "JIT sudo with capability tokens" actually means

The classic sudo model is allow-list-based. An engineer's username appears in /etc/sudoers.d/team with a rule that grants ALL=(ALL) NOPASSWD: ALL or some narrower variant. The grant is durable: it exists until somebody edits the file and re-runs configuration management. Auditing depends on syslog being intact and being shipped somewhere immutable. Revocation depends on configuration management running.

The JIT model inverts the durability. The default state is no sudo. An engineer who needs root for a specific task does one of two things: they hit a self-service approval flow that issues a short-lived token, or they trigger a peer-approval flow in Slack or PagerDuty and a teammate releases the token. The token is a signed capability that names the user, the host or host class, the command pattern, and an expiry. The host enforces it via a PAM plugin during sudo invocation.

The token model has three properties that matter:

• Scoped. A token might grant systemctl restart api* on the "web" host class for 30 minutes, not blanket root.
• Audited. Each issuance writes a row to a tamper-evident log; each sudo invocation under the token writes another row. The chain is verifiable.
• Expires. Tokens lapse on their own. The break-glass case is no longer "remove the engineer from sudoers"; it is "wait until 4pm."

The honest comparison

CyberArk is not a bad product. It is built for a different problem. Here is the comparison without the marketing.

If you have meaningful mainframe accounts, RDP fleets, or a regulator who specifies CyberArk, the table is a draw or a CyberArk win. If your fleet is "a few hundred Linux hosts and a sudo audit problem," the JIT-token row is what matters.

The capability-token format

A capability token is a signed JSON or CBOR object. Here is a representative shape (production tokens use compact binary encoding and ECDSA over the canonical bytes; the structure is the same):

{
  "ver": 1,
  "sub": "alice@example.com",
  "host_class": ["web", "worker"],
  "host_cidrs": ["10.20.0.0/16"],
  "cmd_pattern": "^systemctl (restart|status) api(-[a-z]+)?$",
  "iat": 1716624000,
  "exp": 1716625800,
  "jti": "01HZ8K9XK2X2A0M0J1N2P3Q4R5",
  "approver": "bob@example.com",
  "reason": "INC-1234 api-blue rolling restart"
}

The signature is ECDSA P-256 over the canonical encoding (RFC 8785 JCS, or COSE for the binary variant). The signing key lives in a hardware KMS. The host verifies the signature against the public key it received at enrollment, then checks exp, host_class, host_cidrs, and cmd_pattern before allowing the sudo call to proceed. If any check fails, the call is denied and the failure is logged. The jti is unique; replay attempts against a token already burned (single-use mode) fail closed.

The PAM integration

The mechanism that enforces the token at sudo time is a PAM module. PAM (Pluggable Authentication Modules, originally Solaris 2.3, ported to Linux in 1995) has a stable ABI, so a single binary works across most distributions. The relevant lines in /etc/pam.d/sudo:

# /etc/pam.d/sudo
auth    required   pam_linuxid_jit.so  audit=hashchain
account required   pam_linuxid_jit.so
session optional   pam_linuxid_jit.so  capture=stdout,stderr

The auth step asks the local agent for an active token and verifies the signature and constraints. The session step opens a pty wrapper that captures stdout and stderr to the audit log; the recordings stream to WORM object storage. Sudo proceeds only if every step passes. If the PAM module is missing or fails to load, sudo falls back to /etc/sudoers, which by design contains nothing dangerous (the durable state is "no sudo").

What you keep, what you let go

The honest list of things you give up by choosing JIT-sudo over CyberArk:

• Password vaulting for shared accounts. If you still have shared root passwords or service-account credentials that get rotated quarterly, JIT sudo does not fix that. Use a dedicated secrets manager and stop sharing passwords.
• RDP and Windows session brokering. JIT sudo is Linux only. If you need to record an RDP session into a Windows server, look at Apache Guacamole, Microsoft PIM, or yes, CyberArk PSM.
• Mainframe and exotic protocols. JIT sudo speaks ssh and sudo. If you have z/OS or AS400 in scope, those need a different tool.
• FedRAMP High accreditation. Linux Identity is FedRAMP-track but not yet authorised. If you sell to the US federal government today and need that authorisation, CyberArk Privilege Cloud has it.

What you keep:

• Sudo with cryptographic time bounds and command scoping.
• A hash-chained audit log mapped to SOC 2 CC6.6 and CC7.2 evidence requirements.
• Peer approval flows in the tools your team already uses (Slack, PagerDuty).
• Sub-second issuance latency; engineers do not wait for a vault to round-trip.
• Roughly 95 percent of the budget you would have spent on CyberArk for the Linux portion of your fleet.

Audit log shape and SOC 2 mapping

Audit value depends on what ends up in the log. Every sudo invocation captured by the PAM module produces a row with at least these fields: ISO 8601 timestamp with sub-second precision, IdP-resolved user identity, host identifier, capability token JTI, the actual command argv as the kernel saw it, the working directory, the parent process ID, the exit code, and the sha256 hash of the previous row. The hash chain is what makes the log tamper-evident. A reviewer recomputes the chain from raw rows; any modification breaks the verification at the row where it occurred.

For SOC 2 Type II evidence, this translates as follows. CC6.1 (logical access) gets the IdP identity column and the host enrolment registry, demonstrating that access is restricted to authorised users. CC6.6 (boundary protections) gets the capability-token issuance log, demonstrating that elevation is bounded in time and scope. CC7.2 (system monitoring) gets the sudo invocation log itself, demonstrating that privileged commands are recorded. CC7.3 (incident response) gets the recordings retention policy. Most auditors will ask for one quarter of evidence; the export from this log shape sails through the review.

Compare that to the typical CyberArk PSM audit-evidence package, which produces broadly the same information set, plus password-rotation evidence you do not need if you do not have shared accounts in the first place.

Performance and reliability

A worry that comes up in design review: "What if the token-issuance service is down? Do my engineers lose sudo?" The answer is two-fold. First, token issuance is on the engineer's laptop side: a request to the control plane, signed, returned in well under 100 ms in normal operation. If the control plane is unreachable, the engineer cannot request a new token, but tokens already issued continue to work until their TTL expires. A 30 to 90 minute TTL gives natural slack for a regional outage.

Second, the PAM module on the host is in the verification path, not the issuance path. It does not call out to a network service. It opens the token from the local socket the agent provides, verifies the ECDSA signature against the CA public key it already holds, and checks the constraints. The cryptographic verification adds well under 5 ms to a sudo call. The user does not notice.

The break-glass path covers the case where both the IdP and the control plane are unreachable. A sealed, manually-issued long-lived token in a physical safe restores sudo for one designated incident-response account on a fixed host class. Using the break-glass token writes a high-severity alert into the audit log. In two years of operation across our design partners, it has been used exactly once.

A typical deployment

A 50-engineer fintech with 220 Linux hosts and roughly 40 sudo-needing users moved from "everyone in the platform group has NOPASSWD ALL" to JIT sudo over six weeks. The phases were:

1. Week 1. Install the agent on three pilot hosts. Wire the PAM hook in observe-only mode. Confirm the audit log captures every sudo invocation in the existing sudoers configuration.
2. Week 2 to 3. Define five sudo profiles: read-only, service-restart, deploy, db-incident, fleet-admin. Each maps to a command-pattern regex and a default TTL between 15 and 90 minutes.
3. Week 4 to 5. Roll the agent fleet-wide, still in observe-only mode. Pre-issue tokens that mirror current durable grants, so the rollout is invisible. Confirm the audit log shape matches what the SOC 2 auditor will accept.
4. Week 6. Flip enforcement on. Remove the durable NOPASSWD ALL grants. Engineers now request tokens via linuxid sudo --reason "INC-1234"; for the four most common patterns, the token issues automatically without approval.

Total external spend: well under $20,000 in licences and infrastructure. Total engineer time: about 80 hours, mostly defining the sudo profiles. The CyberArk proposal they had on file for the same scope was $310,000 in year one and a nine-month rollout.

When CyberArk really is the right call

To be balanced: there are organisations for whom CyberArk earns its money. Banks and insurers with mixed-OS fleets and decades of accumulated shared-account passwords. Companies with FedRAMP-High customer requirements that name a specific vendor. Teams whose primary access surface is RDP into Windows servers, where CyberArk PSM for Windows is genuinely first-class.

For a Linux-shop SaaS with SOC 2 as the driver, those conditions rarely apply. JIT sudo with capability tokens is the lighter, cheaper, and frankly more auditable option. See the SOC 2 Linux access article for the control-by-control mapping, or jump straight to Get started to install the agent in five minutes.

Pricing details for fleet sizes from 10 to 1,000+ hosts live on the pricing page. Security posture, including the threat model and KMS-backed signing key custody, is documented on the security page.