CyberArk Pioneered Privileged Access Security. The Privilege Model Has No Cryptographic Governance Layer.
by Nick Clark | Published March 28, 2026
CyberArk effectively defined the privileged access management (PAM) category. Its Digital Vault, Privileged Session Manager, Endpoint Privilege Manager (EPM), Workforce Identity, CyberArk Cloud, and Conjur secrets-management platform together form the most comprehensive privileged-credential security stack in the enterprise market. The credential-protection model is excellent. What CyberArk does not provide — and structurally cannot provide from a vault-and-session vantage point — is cryptographic governance of the operations performed once a credential has been retrieved and used. The vault hardens the key. The cryptographic-governance primitive governs what the key is allowed to do.
1. Vendor and Product Reality
CyberArk Software, founded in Israel in 1999 and listed on NASDAQ since 2014, is the established global leader in privileged access management. The product portfolio is built around the Digital Vault, a hardened, tamper-evident credential store with multi-layered encryption, dual-control workflows, segregated network architecture, and detailed access auditing. Around the vault sit the operational components that make PAM useful at enterprise scale. Privileged Session Manager isolates and records sessions to target systems so that human operators can act under privilege without ever directly handling the credential. Endpoint Privilege Manager removes standing local-administrator rights on workstations and servers and elevates on a least-privilege basis under policy. Workforce Identity extends the identity perimeter to SaaS and workforce applications. CyberArk Cloud delivers the same controls as a managed multi-tenant service. Conjur, acquired in 2017, supplies machine-identity and secrets management for application-to-application authentication, container platforms, Kubernetes workloads, and CI/CD pipelines. CyberArk Secure Cloud Access and Secure Infrastructure Access extend the model to ephemeral cloud-principal access and just-in-time elevation to cloud control planes.
Across that stack, CyberArk makes one thing demonstrably true: privileged credentials are protected at rest, retrieved under policy, used through brokered sessions, rotated automatically, and audited end to end. The customer base spans the Fortune 500, the global banking sector, sovereign defense ministries, and critical-infrastructure operators in energy, transportation, and telecommunications. The platform is the reference implementation for the PAM category as analyst frameworks define it, and it is the platform regulators in financial services, healthcare, and defense routinely cite as satisfying the credential-protection components of their compliance regimes. For the credential-security problem as historically scoped, the platform is comprehensive and battle-tested.
2. The Architectural Gap
The structural limit of the PAM model is what happens after the credential is in use. CyberArk's authority terminates at the boundary of credential delivery. Once a privileged operator, service account, or workload holds an authenticated session, the operations executed under that session are governed by the target system's native authorization — the database's GRANT model, the Linux host's sudoers file, the cloud provider's IAM policy, the Kubernetes role-binding. None of those native controls carry CyberArk's signed governance forward into the operation itself. The credential in use is bearer-equivalent within the target's authorization scope, and the target's scope is almost always coarser than the policy CyberArk would have enforced if it could see the operation.
Privileged Session Manager partially mitigates this through isolation and recording, but isolation protects the credential from exfiltration; it does not bind the operation. A DBA session that legitimately retrieved a credential to run a maintenance script can issue any SQL the target permits, including DROP TABLE on tables the maintenance script never names. A break-glass cloud-admin session can perform any API call the underlying role allows, including creating new privileged principals, exfiltrating data through legitimate APIs, or modifying the audit configuration of the cloud account itself. Recording produces forensic evidence after the fact. It is not cryptographic governance during the fact.
Conjur extends the same model to machine identities — applications and workloads fetch secrets under policy — but again, once the secret is fetched, the operations performed with it are outside Conjur's governance scope. A compromised microservice that legitimately holds a database secret can issue any query that the database role grants. The vault, the session manager, and the secrets broker collectively answer "who got the credential, when, and through what workflow." They do not answer "and is this specific operation, executed right now under that credential, permitted by signed policy with cryptographic non-execution proof for the operations that policy denies?" That second question is the cryptographic-governance primitive, and it is the question regulators in defense, sovereign cloud, and financial-market infrastructure are increasingly asking by name. The PAM model cannot answer it because the architectural vantage point is wrong: PAM watches the door, not the room.
3. The AQ Cryptographic-Governance Primitive
The Adaptive Query cryptographic-governance primitive specifies that every privileged operation be admitted at execution time under a capability credential whose constraints are signed at issuance and verified at use, and that operations falling outside the capability produce a cryptographic non-execution proof rather than a silent native-authorization failure. The primitive is composed of three structural elements that together close the gap PAM cannot close from the credential-delivery boundary.
The first element is the capability credential itself: a signed, structured object that names not just an authenticating principal but the operation classes the principal is admitted to perform, the contextual conditions under which admission holds (time window, source location, target object class, transactional scope), the freshness window beyond which the capability expires regardless of credential validity, and the admission predicate the operation must satisfy at execution. The capability is bound to the credential at the issuance point and travels with the credential through whatever transport, broker, or session manager is in use. The second element is the operation-time admission gate, which evaluates each proposed operation against the bound capability and admits only operations that satisfy the predicate. The gate is not a wrapper around the target's native authorization; it is an architectural element interposed between the credentialed principal and the target, with its own signing key and its own audit trail. The third element is the cryptographic non-execution proof, which is produced for every operation the gate refuses: a signed, non-repudiable record naming the operation, the credential under which it was attempted, the bound capability, the failed admission predicate, and the timestamp. Non-execution proofs are first-class governance evidence rather than the absence of evidence that a silent native denial produces.
The primitive is technology-neutral with respect to signature scheme, transport, and underlying credential format, and it composes hierarchically: capability credentials can be derived from parent capabilities under a signed derivation rule, which means an enterprise root authority can issue a coarse capability to a business unit, which derives a finer capability to a service, which derives a still-finer capability to a specific operation invocation, with each derivation cryptographically traceable to its parent. The structural condition the primitive imposes is that no privileged operation executes without admission against a signed capability and without a corresponding non-execution proof for any refused alternative.
4. Composition Pathway
Cryptographic governance does not replace the vault. It binds operation-level policy to the credential as a first-class capability whose constraints persist through use. When CyberArk releases a credential — to a human operator via Privileged Session Manager, to a workload via Conjur, to a cloud principal via CyberArk Cloud — the credential is issued together with a signed governance binding that names the permitted operation classes, the contextual conditions, the freshness window, and the admission predicate the credential resolves under. CyberArk's existing policy model becomes the authoring surface for capability constraints: the policies operators already write in CyberArk's policy editor are compiled into capability bindings rather than into vault-level access rules alone.
At execution time, each operation issued under the credential transits the AQ admission gate before reaching the target system. The gate verifies the capability, evaluates the predicate against the proposed operation and the runtime context, and either admits or produces a non-execution proof. The target system continues to apply its native authorization as a defense-in-depth layer, but the architectural primary is the gate's signed admission. CyberArk's existing operational surface is preserved end-to-end: the Digital Vault still hardens the credential, PSM still brokers and records the session, EPM still elevates locally, Conjur still distributes secrets, Workforce Identity still federates SSO, and CyberArk Cloud still delivers the same controls as a managed service. What changes is that every credential CyberArk releases now carries governance that travels with it, and every operation performed under that credential is resolved against signed policy rather than against the target's native authorization alone.
The integration points are well-defined. Conjur's secret-fetch event becomes a capability-issuance event, with the capability scope derived from the requesting workload's identity attestation. PSM's session-establishment event becomes a session-bound capability issuance, with the capability constrained to the session's stated purpose, target class, and time window. CyberArk Cloud's just-in-time elevation event becomes a capability derivation from a coarser cloud-tenant capability under a signed derivation rule. The architecture turns CyberArk's credential events into the issuance points for capability credentials whose use is cryptographically governed downstream, and CyberArk's audit pipeline absorbs both the admission proofs and the non-execution proofs as first-class evidence.
5. Commercial and Licensing Implication
The fitting commercial structure is an embedded primitive license: CyberArk embeds the AQ cryptographic-governance primitive into the Digital Vault, PSM, Conjur, and CyberArk Cloud, and sub-licenses capability-credential issuance and admission-gate operation to its enterprise customers as part of the platform subscription. Pricing aligns with how regulated customers actually consume governance — per-capability-class, per-protected-target, or per-mutation-rate — rather than the per-seat or per-vault-account models PAM has historically used. The licensing structure accommodates the multi-tier customers (sovereign cloud operators, federated defense supply chains) where capability derivation rules cross corporate boundaries and the parent-child capability relationship has its own commercial value.
What CyberArk gains commercially is a structural answer to the "trust the PAM platform's own evidence" problem that current SOC 2 and FedRAMP attestation only addresses procedurally, a defensible position against in-platform competition from BeyondTrust, Delinea, HashiCorp Vault, AWS Secrets Manager, and Microsoft Entra Privileged Identity Management by elevating the architectural floor of the category from credential protection to operation-level cryptographic governance, and a forward-compatible posture against the EU AI Act's high-risk-system operational-control requirements, the U.S. Department of Defense's CMMC 2.0 Level 3 evidentiary standards, the SEC's cyber-incident-disclosure rule, and the emerging post-quantum signature requirements that defense and sovereign-cloud customers are already specifying in procurement. What the customer gains is concrete: insider misuse under legitimately retrieved credentials — historically the hardest PAM failure mode to prevent — becomes architecturally bounded rather than forensically observed; compliance regimes that require demonstrable separation between credential possession and operation authorization gain a primitive that satisfies the requirement directly rather than by procedural overlay; and the audit story moves from "we recorded the session" to "we can produce cryptographic evidence that every operation under this privilege was admitted by a signed policy whose resolution is independently verifiable." Honest framing — the AQ primitive does not replace PAM; it gives PAM the operation-plane governance it has always implied and never had. The vault secures access. Cryptographic governance governs use.