Privileged Access Management in Defense Networks: PAM With Classification Awareness

Privileged Access Management (PAM) in a defense network is not the same problem PAM solves in a commercial enterprise. A bank that gets PAM wrong loses customer data; a defense organization that gets PAM wrong loses the network — and the operations running on it. The accreditation authority knows this, and the audit chain reflects it. This article walks through the engineering decisions that separate a defense-grade PAM rollout from a commercial one, drawing on the patterns we have seen succeed (and fail) inside classified enclaves, SCIF-resident workflows, and OT estates. For the broader picture, see our complete guide to defense cybersecurity.

1. Why PAM in Defense Is Different

Three properties make defense PAM structurally different from commercial PAM. First, users are multi-classification: the same human operator may hold accounts on an unclassified administrative LAN, a SECRET mission network, and a TOP SECRET intelligence enclave, and the PAM platform must never mediate a credential across that boundary. Second, the highest-value workflows are SCIF-resident — the user, the workstation, the jump host, and the vault are all inside the same accredited room, and any component that lives outside the SCIF is, by definition, the wrong architecture. Third, the audit-chain expectation is far stricter than commercial: the accreditation authority does not accept "we have logs" — it expects a tamper-evident, replayable, retention-bounded record of every privileged action, mapped back to a cleared individual, and survivable when the network is offline for weeks.

The practical consequence is that "deploy CyberArk and you're done" — the answer that works in most commercial deployments — is not the answer in defense. The platform choice matters less than the enclave topology, the brokering model, and the audit pipeline. We have seen organizations buy the right product and still fail accreditation because they collapsed two classification levels into one vault.

2. CyberArk / HashiCorp Vault / BeyondTrust / Delinea

CyberArk remains the incumbent for classified deployments at NATO-member defense organizations. Its Privileged Session Manager (PSM) is mature, FIPS 140-2 validated, and the Enterprise Password Vault has Common Criteria EAL4+ certification — both line items the accreditor will check first. The cost is steep, and the licensing model assumes connectivity to CyberArk's update infrastructure, which forces an offline-update workflow inside air-gapped enclaves.

HashiCorp Vault (Enterprise) is the choice when the workload is API-driven, ephemeral, and Kubernetes-adjacent. Its dynamic-secrets and PKI engines are excellent for short-life X.509 issuance, which is increasingly how modern defense workloads authenticate. Vault Enterprise supports FIPS 140-2 mode and HSM integration via PKCS#11. Its weakness in a defense context is session brokering — Vault is a secrets engine, not a session proxy, so an interactive-admin workflow needs a separate component (Boundary, or a third-party bastion) layered on top.

BeyondTrust (Password Safe + Privileged Remote Access) has the strongest OT/ICS story of the four. Its jump-host model was designed for vendor-managed remote access into industrial plant, which maps cleanly onto the depot-maintenance and OEM-support workflows defense logistics organizations actually run. FIPS 140-2 validated; the session-recording pipeline is the most mature of any product in this category.

Delinea (formerly Thycotic + Centrify) is the lighter-weight option, often chosen for sub-enclaves where the full CyberArk footprint is overkill. Secret Server is FIPS 140-2 validated; the Server Suite covers AD-bridging for Linux/Unix that the older defense estates still depend on.

Across all four, the FIPS 140-3 transition is in progress — 140-2 validations remain accepted under transitional rules through the 2026 accreditation cycle in most NATO contexts, but new deployments should be specifying 140-3 where the vendor offers it. Common Criteria coverage is uneven; CyberArk and BeyondTrust have the deepest schedules.

3. Classification-Aware Session Brokering

The single most consequential architectural decision in defense PAM is whether the platform brokers sessions across classification boundaries — and the correct answer is always "no." Each enclave gets its own vault, its own session manager, and its own audit store. The credential for the SECRET admin account never exists in the unclassified vault, even encrypted, even "for break-glass." If accreditation finds a single record of a higher-classification credential inside a lower-classification component, the entire deployment is back to square one.

Cross-enclave session escalation — the workflow where an operator on the unclassified side needs to reach a SECRET host — is solved at the cross-domain-solution (CDS) boundary, not inside the PAM platform. The operator authenticates inside the higher-classification enclave; the CDS does not pass credentials across. The PAM platform on each side is unaware of the other. This maps cleanly onto the zero-trust military networks model where every enclave is its own trust domain.

For SCIF-resident workflows, the vault, the session manager, and the audit collector all live inside the SCIF. The temptation to host the management plane outside the SCIF "for ease of administration" is the most common architectural mistake we see, and it is non-recoverable — the accreditor will not approve a remote management channel into a SCIF-resident credential store, no matter how it is encrypted.

4. Just-in-Time (JIT) Elevation

JIT elevation is the discipline of granting privileged access only at the moment it is needed, for the duration it is needed, and revoking it automatically afterward. In defense networks it replaces the long-standing pattern of "the maintenance team has Domain Admin permanently because they sometimes need it at 3 a.m." — which is exactly the pattern an adversary with persistent access exploits.

The architecture has three components. First, a request workflow — typically integrated with the ticketing system — where the operator asks for elevation, with a stated reason and a stated duration. Second, an approval path: for routine maintenance, this can be policy-automated; for break-glass into OT systems or cryptographic key material, it requires a second cleared operator's approval (four-eyes principle). Third, an issuance mechanism: the PAM platform mints a time-bounded credential — an ephemeral SSH certificate (typically 1–4 hours), a short-life X.509 client cert for API access, or a temporary AD group membership that expires on a scheduled timer.

Ephemeral SSH certificates are the cleanest pattern for Linux/Unix administration: the operator's request triggers Vault (or CyberArk's equivalent) to mint a certificate signed by the SSH CA, scoped to specific hosts, with a 4-hour validity. No long-lived public key ever sits on the target host, and revocation is automatic when the cert expires. For Windows administration, short-life X.509 client certs combined with smart-card readers achieve the same property, leveraging the hardware root of trust already present on most defense workstations.

5. Service Accounts and Secrets

The vendor-recommended rotation cadences — 30 days for service accounts, 90 days for application secrets, annual for root CA keys — are the easy part. The hard part is rotating under air gap. A connected enterprise rotates a service account password and the new credential propagates through Active Directory, the secrets store, the consuming application, and the monitoring system in seconds. Inside an air-gapped enclave, every one of those steps is manual, scheduled, and risk-bearing — and the maintenance window is measured in single-digit hours, often at night, often with a backup operator on standby.

The realistic operational answer is tiered cadences: high-value credentials (Domain Admin, root CAs, KMS unlock keys) rotate on accelerated schedules with full change-control discipline; medium-value credentials (database service accounts, application principals) rotate via automated PAM workflows during scheduled maintenance windows; low-value but long-lived credentials (legacy app accounts, embedded device passwords) get inventoried, vaulted, and rotated on the slowest cadence the risk register will accept.

The long-lived-credential reality is the one audit always catches. Every defense estate of any size has a long tail of service accounts created in 2014 for a system nobody owns anymore, with the password in a wiki page that has been migrated four times. The PAM rollout discovers these, and the discovery itself is the value — even if the rotation takes another year.

6. PAM for OT / Industrial Plant

Operational Technology — the industrial control systems running depot machinery, base power infrastructure, fuel storage, and increasingly the manufacturing lines feeding the defense supply chain — is the hardest PAM environment in any defense organization. Three patterns dominate.

First, jump-host architecture: every administrative connection into the OT network terminates at a hardened bastion that brokers the protocol (RDP, VNC, serial-over-IP), enforces session recording, and isolates the operator's workstation from the control network. BeyondTrust's Privileged Remote Access product is the reference implementation here; CyberArk's PSM for SSH and the open-source Apache Guacamole pattern cover the same ground at different cost points.

Second, the password-not-changed-in-15-years problem. PLCs, HMIs, and historian servers shipped from the OEM with default or rarely-rotated credentials, and rotating them risks bricking the device or breaking a vendor support contract. The pragmatic answer is to vault the credential (so at least the access path is audited and the cleartext is removed from operator memory and post-it notes), defer rotation until the next scheduled outage window, and document the residual risk in the accreditation package.

Third, vendor-managed remote access. OEM technicians need to reach the equipment for warranty support. The PAM platform mediates this as a fully recorded, time-bounded session brokered through the jump host — never a permanent VPN tunnel into the OT network. The vendor's account is JIT-issued, the session is recorded end-to-end, and the cleared operator on the defense side approves and observes.

7. Audit Chain and Session Recording

The audit chain is the artifact the accreditation authority cares about most, and it is the one defense PAM rollouts most often under-build. Three layers matter. Keystroke logging captures the literal commands an operator typed in a privileged session — invaluable for forensics, expensive in storage, and subject to retention discipline. Video session recording captures the rendered RDP/VNC frames — non-negotiable for SCADA/HMI sessions where the operator's interaction is graphical, not textual. Command-level audit captures the structured event ("user X elevated to role Y on host Z at time T for ticket #N") — the layer the SOC actually consumes in SIEM correlation and zero-trust verification.

Long-retention discipline is where commercial PAM playbooks fall short. Defense retention horizons routinely reach 7–10 years, sometimes longer for nuclear-adjacent or strategic-systems contexts. The storage tier must be immutable (WORM-class, or write-once object storage with retention locks), the integrity must be cryptographically anchored (signed manifests, hash-chained logs), and the retrieval path must work in 2034 with the people and tooling available then — not the people available today.

GDPR and NIS2 alignment matters in EU defense contexts. Session recording captures personal data (the operator's keystrokes, sometimes their face on a webcam-enabled session). The lawful basis under GDPR is typically "legal obligation" plus "legitimate interest," with documented retention limits and access controls. NIS2 reinforces this with explicit incident-response and audit-availability requirements that PAM logging directly serves.

8. Migration and Co-Existence

The realistic timeline to bring an AD-only defense estate into modern PAM is two to four years. The first year is discovery and vaulting: every privileged credential is inventoried, vaulted, and brought under check-out/check-in workflow, without yet changing how operators work. The second year is session brokering: interactive admin sessions move behind the PAM proxy, recording starts, and the audit chain comes online. The third year is JIT elevation and rotation: permanent privileges are converted to time-bounded, and rotation cadences are enforced. The fourth year, if needed, is cleanup of the long-tail service accounts and OT credentials.

Co-existence with legacy AD-only patterns is the norm, not the exception, for most of this timeline. The PAM platform brokers access to AD-joined hosts, vault AD credentials, and gradually replaces standing Domain Admin membership with JIT elevation via shadow groups. Trying to cut over the entire estate in a single weekend has failed every time we have seen it attempted.

The hard-won lesson: PAM rollback is worse than slow rollout. Once an operator population has been moved onto vault-brokered, JIT-elevated, fully-audited workflows, rolling back to the old "Domain Admin permanently" pattern is operationally and culturally near-impossible — the audit gap is visible, the SOC has come to depend on the telemetry, and the accreditation package has been updated. A partial rollout that holds is better than a full rollout that has to be reversed. Plan the phases so each phase is independently stable, and treat the multi-year cadence as a feature, not a bug.