CyberArk Conjur EU Alternative 2026: NASDAQ:CYBR's Dual-HQ Structure and the Enterprise DevOps Secrets Paradox

Post #1260 in the sota.io EU Secret Management Series

CyberArk is the dominant force in enterprise privileged access management — and through Conjur, it has extended that dominance into DevOps machine secrets. Conjur is CyberArk's purpose-built secrets management platform for developer workflows, CI/CD pipelines, Kubernetes clusters, and cloud-native applications. Where CyberArk's PAM products protect human privilege, Conjur protects machine privilege: the API keys, TLS certificates, database passwords, and service-to-service tokens that modern microservice architectures depend on.

But CyberArk presents a jurisdictional puzzle that matters deeply for EU organisations subject to GDPR, NIS2, DORA, or the EU Cyber Resilience Act. CyberArk Software Ltd. is an Israeli company listed on NASDAQ. Its US subsidiary, CyberArk Software Inc., is incorporated in Delaware and operates the commercial infrastructure serving most enterprise customers. The US subsidiary is unambiguously subject to the CLOUD Act (18 U.S.C. §2713). That means every machine secret in Conjur Cloud — every database password protecting an EU payment processor, every Kubernetes service account token authorising deployments to EU production, every certificate anchoring mTLS between EU microservices — is legally compellable by the US Department of Justice.

This creates what we call the Enterprise DevOps Secrets Paradox: the most security-focused secrets management platform in the enterprise market stores your secrets under a jurisdiction that can compel their disclosure without your knowledge, without an EU court order, and without the data subject notification requirements GDPR demands.

This post analyses CyberArk's corporate structure, scores Conjur's CLOUD Act exposure at 18/25, maps the specific GDPR risks, and evaluates the EU-viable alternatives for organisations that cannot afford to hand their machine secrets to a foreign jurisdiction.

CyberArk Software Ltd.: Corporate Structure and the Dual-HQ Jurisdiction

Legal entity (parent): CyberArk Software Ltd. Country of incorporation: Israel Stock exchange: NASDAQ (CYBR) — US-listed Israeli company US headquarters: Newton, Massachusetts, USA Israel headquarters: Petah Tikva, Israel Founded: 1999 (Israel) Employees: ~8,000 (2026)

US operating entity: CyberArk Software Inc. State of incorporation: Delaware, USA Role: Principal commercial operating entity for North American and most international enterprise sales

CyberArk's corporate structure requires careful parsing. The parent company, CyberArk Software Ltd., is incorporated in Israel and listed on NASDAQ. Israel has a bilateral data-sharing arrangement with the EU under the GDPR adequacy framework — the European Commission recognised Israel as providing adequate protection under Directive 95/46/EC, a finding that has been carried forward under GDPR Article 45.

This Israeli adequacy decision might appear to protect EU organisations. It does not — for a specific and legally significant reason.

CyberArk's US subsidiary, CyberArk Software Inc. (Delaware), is a US person under the CLOUD Act. 18 U.S.C. §2713 requires any "provider of electronic communication service or remote computing service" that is a US person — or whose parent company is — to produce customer data in response to a valid US legal process, regardless of where that data is stored. CyberArk Software Inc. is the entity that contracts with enterprise customers, operates the Conjur Cloud SaaS infrastructure, and stores the secrets.

The Israeli parent's adequacy status is irrelevant. What matters is that the US subsidiary — the legal entity holding and processing your secrets — is subject to US jurisdiction. The CLOUD Act does not care whether the parent company is Israeli. It applies to the US operating entity.

Conjur's history reinforces this: Conjur was originally developed by Conjur Inc., a Delaware-incorporated startup founded in 2012 in Boston, Massachusetts. CyberArk acquired Conjur Inc. in 2017. The product has been US-incorporated since its founding, and its commercial infrastructure was built under US legal frameworks.

What CyberArk Conjur Stores: Why Secrets Are Maximum-Sensitivity Data

CyberArk Conjur is designed for enterprise-scale machine secrets management. To understand the jurisdictional stakes, it is essential to understand what Conjur actually stores and why machine secrets represent a uniquely sensitive data category.

Conjur's core data types:

Dynamic secrets: Conjur generates short-lived, just-in-time credentials for databases, cloud platforms, and services. A Conjur-managed PostgreSQL dynamic secret is a username and password pair that expires after minutes or hours — but while active, it grants full database access. Under the CLOUD Act, US law enforcement can compel CyberArk to produce these rotation records, policy definitions, and audit trails.

Static secrets and certificates: TLS certificates, SSH private keys, long-lived API tokens, and service account credentials are stored in Conjur's vault. These are the credentials that service-to-service communication depends on. A CLOUD Act subpoena for these secrets is equivalent to handing the US DOJ the keys to your entire microservice mesh.

Kubernetes secrets integration: Conjur integrates deeply with Kubernetes via its Secrets Provider sidecar and the Conjur Provider for External Secrets Operator. Kubernetes pods authenticate to Conjur using their workload identity and receive secrets at runtime. The authentication metadata, policy bindings, and secret values pass through Conjur's cloud infrastructure.

CI/CD pipeline secrets: Conjur's Jenkins plugin, GitLab integration, GitHub Actions support, and Terraform provider inject secrets into CI/CD pipelines at build time. A CLOUD Act request covering these integration logs reveals your entire DevOps toolchain and the credentials protecting each stage.

Policy and RBAC data: Conjur's YAML-based policy language defines who (or what) can access which secrets under what conditions. These policies are sensitive in themselves — they document your entire production access control architecture.

Under GDPR Article 4(1), personal data includes "any information relating to an identified or identifiable natural person." Service account credentials associated with individual developers, audit trails recording which engineer fetched which secret, and session tokens tied to named Kubernetes service accounts all constitute personal data. More broadly, under GDPR Article 32, the security of processing requires that appropriate technical measures protect against "unauthorised access to" personal data systems — and the credentials protecting those systems are core to that requirement. Storing those credentials in a CLOUD Act-exposed platform is itself a technical security gap.

CLOUD Act Exposure Score: CyberArk Conjur

We score CyberArk Conjur across five CLOUD Act risk dimensions, each rated 0-5:

D1: Corporate Structure and Jurisdiction (4/5)

CyberArk Software Inc. (Delaware C-Corp) is the US operating entity handling enterprise contracts and cloud infrastructure. It is unambiguously a US person under 18 U.S.C. §2713. The Israeli parent (CyberArk Software Ltd.) does not shield the US subsidiary from CLOUD Act compulsion. Score: 4/5 (not maximum only because the Israeli parent structure creates minor procedural complexity for DOJ requests, though this has never been a successful defence).

D2: Government and Intelligence Relationships (4/5)

CyberArk has deep and documented relationships with US government and intelligence communities. The company holds a US Federal civilian agency ATO (Authority to Operate), and CyberArk PAM is authorised on multiple FedRAMP-tracked platforms. CyberArk's products protect infrastructure at US federal agencies, the DoD supply chain, and IC-adjacent organisations. CyberArk has not published a canary statement or transparency report documenting US government data requests.

Additionally, CyberArk's Israeli origins create a distinct intelligence angle: Israel's Unit 8200 — the Israeli Intelligence Corps' technology unit — has produced a disproportionate share of Israeli cybersecurity company founders. CyberArk's founders include veterans of Israeli intelligence and military cybersecurity programmes. This does not create legal compulsion under the CLOUD Act, but it is context that EU security teams conducting threat modelling should weigh. Score: 4/5.

D3: Sensitivity of Stored Data (5/5)

Machine secrets represent the maximum possible data sensitivity in a cloud-native architecture. They are not the data — they are the access rights to all the data. A CLOUD Act request that produces Conjur vault contents does not compromise one dataset, one system, or one service. It compromises everything those secrets protect.

For an enterprise running 50+ microservices across three cloud regions, with database passwords, API tokens, TLS private keys, and Kubernetes service account credentials in Conjur, a successful CLOUD Act subpoena produces the equivalent of the master key to every lock in the building. Score: 5/5 (maximum — machine secrets are categorically the highest sensitivity class in DevOps infrastructure).

D4: Hosting Infrastructure and Data Residency (3/5)

Conjur Cloud, CyberArk's SaaS offering, runs primarily on AWS infrastructure. CyberArk offers data residency options including EU-based AWS regions (eu-west-1 Ireland, eu-central-1 Frankfurt). However, data residency does not limit CLOUD Act jurisdiction — the data can be physically in Frankfurt while remaining legally compellable under US law because the operating entity (CyberArk Software Inc., Delaware) is a US person. CyberArk's own documentation acknowledges that EU hosting does not guarantee exemption from US legal process. Score: 3/5.

D5: Contractual Protections and Encryption Architecture (2/5)

CyberArk's enterprise agreements include Standard Contractual Clauses for EU data transfers under GDPR Article 46. However, SCCs represent a contractual commitment to protect data — they do not represent a technical barrier to CLOUD Act compliance. If a US court order requires CyberArk Software Inc. to produce your Conjur secrets, SCCs do not prevent this. CyberArk does not offer customer-managed encryption keys (CMEK) for Conjur Cloud in a configuration where CyberArk itself cannot access the decrypted secrets. Score: 2/5.

Total CLOUD Act Score: 18/25

For reference: HashiCorp Vault Enterprise (HCP Vault) scored 18/25 in Post #1258; Doppler scored 15/25 in Post #1259. CyberArk Conjur's elevated D2 government relationship score reflects its deeper federal footprint.

The Enterprise DevOps Secrets Paradox

CyberArk occupies a unique position in the secrets management market that creates a specific GDPR risk pattern we call the Enterprise DevOps Secrets Paradox.

Most secrets management vendors focus on either PAM (human privilege) or DevOps secrets (machine privilege). CyberArk spans both through a single platform:

• CyberArk PAM/Privileged Cloud: Manages human administrative credentials — the passwords vault administrators use to access databases, servers, and network devices
• CyberArk Conjur: Manages machine credentials — the automated secrets that services use to communicate with each other without human intervention

When both layers run through CyberArk's US subsidiary, a single CLOUD Act request can simultaneously expose:

• Your IT administrators' privileged session recordings (PAM layer)
• Every machine-to-machine credential authorising automated production access (Conjur layer)
• The policy definitions documenting who has access to what and under what conditions
• The audit trail showing every secret access event across your entire infrastructure

For organisations that have adopted CyberArk as their unified privilege platform — which is precisely the enterprise consolidation strategy CyberArk's sales team promotes — the jurisdictional exposure is not additive. It is multiplicative.

GDPR Article 28 (Processor relationships): Any EU DPA audit of an organisation's GDPR processor agreements will reach CyberArk. The auditor's question is straightforward: "Can the US DOJ compel your PAM and secrets management provider to produce your privileged credentials and access policies without notifying you or your organisation?" The honest answer is yes.

NIS2 Article 21(2)(d) (Supply chain security): NIS2 requires essential and important entities to implement "security of supply chain" measures for their ICT systems. CyberArk represents a supply chain dependency for the secrets infrastructure itself. A CLOUD Act subpoena targeting CyberArk does not just affect CyberArk — it affects every system CyberArk protects.

DORA Article 28 (ICT third-party risk): Financial entities subject to DORA must maintain a register of all ICT third-party service providers and conduct proportionate due diligence. For a Conjur deployment protecting trading platform credentials, payment service API keys, and core banking service certificates, the DORA risk assessment must account for CLOUD Act exposure. Most DORA ICT risk assessments do not currently include this analysis — a gap that EU financial supervisors are increasingly identifying in examinations.

Conjur Open Source: The Self-Hosted Alternative

CyberArk maintains an open-source version of Conjur under the Apache 2.0 licence: Conjur Open Source (conjur-oss).

For EU organisations seeking to eliminate CLOUD Act exposure while retaining Conjur's workflow integrations, self-hosted Conjur OSS on EU infrastructure is a technically viable path. The open-source edition includes:

• The core Conjur policy engine (YAML-based RBAC)
• REST API compatible with Conjur Cloud clients
• Kubernetes Secrets Provider sidecar
• Summon (injector for CLI and shell scripts)
• Integrations for Ansible, Terraform, and Jenkins

Limitations vs. Conjur Enterprise/Cloud:

• No high-availability clustering in OSS (requires Conjur Enterprise for HA)
• No built-in disaster recovery tooling
• No FIPS 140-2 validation
• No CyberArk support SLA
• Operational burden falls entirely on the EU organisation

For EU organisations with Kubernetes-heavy workloads and existing CyberArk enterprise agreements, self-hosted Conjur OSS on Hetzner Germany or an EU cloud provider — combined with CyberArk support for the self-hosted deployment — represents a path to jurisdictional sovereignty while retaining operational familiarity.

However, EU legal teams should note: using Conjur OSS code created by CyberArk Software Inc. (a US person) does not itself create CLOUD Act exposure. The CLOUD Act compels US persons to produce data they store or control — not data stored by third parties who happen to use their open-source code. Self-hosted Conjur on EU infrastructure, operated entirely by EU personnel, falls outside CLOUD Act jurisdiction.

EU Alternatives to CyberArk Conjur

Infisical (Open-Source, EU-Hostable)

Infisical is an open-source secrets management platform incorporated in San Francisco (US entity, CLOUD Act applicable for hosted version) but designed for self-hosted deployment. For CLOUD Act avoidance, the relevant configuration is Infisical self-hosted on EU infrastructure.

Infisical self-hosted on a Hetzner, OVHcloud, or Scaleway instance is fully outside US jurisdiction. The codebase is MIT-licensed. Infisical provides:

• Dynamic secrets for PostgreSQL, MySQL, AWS, GCP, and Azure
• Kubernetes Operator for secret injection
• Terraform provider
• GitHub Actions, GitLab CI, and Jenkins integrations
• End-to-end encryption architecture (secrets encrypted client-side before storage)
• RBAC with granular policy controls

The hosted Infisical Cloud (infisical.com/eu) runs on AWS eu-central-1. It uses EU data residency but remains subject to CLOUD Act via the US parent entity — the same structural issue as Conjur Cloud. For jurisdictional sovereignty, self-hosted is required.

CLOUD Act score (self-hosted EU): 0/25 — no US person stores or controls the data.

OpenBao (Linux Foundation, Apache 2.0)

OpenBao is the Linux Foundation fork of HashiCorp Vault, created in 2024 after HashiCorp's acquisition by IBM and the licence change from MPL 2.0 to BUSL. OpenBao maintains API compatibility with Vault and is governed by the Linux Foundation as a vendor-neutral project.

OpenBao deployed on EU infrastructure is the most direct enterprise-grade alternative to Conjur for organisations already familiar with HashiCorp's ecosystem. OpenBao includes:

• Dynamic secrets (database, cloud credentials, PKI)
• Kubernetes authentication backend
• Transit encryption-as-a-service
• OIDC/JWT authentication
• Active Community Edition and enterprise features roadmap

OpenBao's Linux Foundation governance means no single US corporate entity controls the codebase or the hosted infrastructure (when self-hosted). For EU organisations subject to DORA or NIS2, the open governance model also supports supply chain security analysis under Article 21(2)(d) and DORA Article 28.

CLOUD Act score (self-hosted EU): 0/25 — Linux Foundation is a US non-profit, but self-hosted operation on EU infrastructure by EU entities falls outside CLOUD Act compulsion.

Bitwarden Secrets Manager (US entity, open-source)

Bitwarden Secrets Manager is Bitwarden Inc.'s machine secrets product. Bitwarden is incorporated in Delaware (US person, CLOUD Act applies to hosted version). However, like Infisical, the codebase is fully open-source and can be self-hosted.

Self-hosted Bitwarden Secrets Manager on EU infrastructure eliminates CLOUD Act exposure. The product covers:

• Machine secrets storage (API keys, tokens, credentials)
• SDK integrations for TypeScript, Python, Go, Rust, Java, C#
• GitHub Actions integration
• CLI for CI/CD injection

Bitwarden Secrets Manager is less feature-rich than Conjur for complex Kubernetes environments — it lacks the dynamic secrets capability and the Kubernetes Secrets Provider sidecar — but for teams with simpler secrets workflows, the operational simplicity and open-source auditability are significant advantages.

CLOUD Act score (self-hosted EU): 0/25.

Comparison Table

What "Enterprise-Scale" CLOUD Act Exposure Means

CyberArk Conjur is marketed primarily at enterprise organisations — the Global 2000, regulated industries, government agencies, financial institutions. These are the organisations with the most to lose from CLOUD Act exposure, because they typically have:

1. The most sensitive secrets: A European investment bank's Conjur deployment might contain credentials for trading platform APIs, clearing house connections, regulatory reporting databases, and risk management systems. A CLOUD Act subpoena produces a map of the entire operational architecture.

2. The strictest regulatory obligations: NIS2 essential entities, DORA financial entities, GDPR processors handling sensitive categories — these are precisely the organisations CyberArk targets, and precisely the organisations EU regulators are most focused on.

3. The deepest CyberArk integration: Enterprises that deploy Conjur typically integrate it with their CI/CD pipelines, their Kubernetes clusters, their cloud IAM, and their CyberArk PAM platform. The secrets exposure is not a single vault — it is the entire secrets infrastructure.

4. The least tolerance for unplanned disclosure: A startup losing API keys through a CLOUD Act request is bad. A NIS2 essential entity — a hospital, an energy operator, a financial market infrastructure — losing privileged credentials through a foreign government's legal process creates systemic risk.

The CLOUD Act's scope is not bounded by the sensitivity of the data or the importance of the organisation. The US DOJ can compel production for a broad range of criminal investigations. The organisation's secrets do not need to be the subject of the investigation — they need only be held by a US person who has received a valid legal process.

Procurement Checklist for EU Organisations

Before deploying CyberArk Conjur Cloud (or any SaaS secrets manager operated by a US entity), EU data protection teams should address the following:

Legal basis questions:

• Under GDPR Article 44, what is the transfer mechanism for secrets data processed by a US entity? SCCs? Adequacy? None?
• Does your DPIA (Article 35) account for CLOUD Act exposure as a residual risk after SCCs?
• Has your DPO reviewed the implications of CyberArk Software Inc.'s US personhood for your GDPR Article 28 processor agreement?

NIS2/DORA questions:

• Does your ICT third-party risk register (DORA Article 28) include CyberArk Conjur as a critical dependency?
• Have you assessed the supply chain risk (NIS2 Article 21(2)(d)) of the secrets management layer being subject to US jurisdiction?
• What is your documented incident response procedure for a scenario where CyberArk receives and complies with a CLOUD Act subpoena covering your secrets?

Technical questions:

• Is customer-managed encryption key (CMEK) architecture available such that CyberArk cannot decrypt your secrets without your cooperation?
• Is the Conjur Cloud audit log immutable and independently accessible by your organisation?
• Can you export your entire Conjur policy and secrets inventory to an EU-controlled backup on demand?

If these questions do not have satisfactory answers, EU-hosted self-managed alternatives should be evaluated before procurement.

Conclusion: Enterprise Secrets Sovereignty Requires Architecture Decisions, Not Vendor Trust

CyberArk Conjur is an excellent product from a security engineering perspective. The RBAC policy model, dynamic secrets rotation, Kubernetes integration, and enterprise support are genuine competitive advantages. This post does not argue that CyberArk is negligent or malicious. It argues that CyberArk Software Inc. is a US person, and that US persons are legally obligated to comply with CLOUD Act orders — regardless of their own preferences, their customers' preferences, or the protections offered by GDPR, NIS2, or DORA.

The question for EU organisations is not whether CyberArk would comply with a CLOUD Act order. It is whether your regulatory obligations, threat model, and organisational risk tolerance can accept secrets infrastructure that is legally compellable by a foreign government.

For organisations where the answer is no, self-hosted alternatives exist. Conjur OSS on EU infrastructure, Infisical self-hosted, and OpenBao each provide enterprise-grade secrets management without CLOUD Act exposure. The operational overhead of self-hosting is real — but for regulated EU entities, it is almost always lower than the risk and remediation cost of a regulatory finding that your NIS2 or DORA compliance evidence was stored in a CLOUD Act-exposed US system.

sota.io is an EU-native managed PaaS — built in Germany, no US parent, no CLOUD Act exposure. Start deploying your applications on infrastructure that keeps your data in EU jurisdiction.