About the security of 1Password confidential computing

Learn how 1Password keeps your data end-to-end encrypted across cloud services.

End-to-end encryption is the heart of 1Password’s security model. Your passwords and other secrets are encrypted on your device before being sent to the cloud. Without your encryption keys, which are derived from your account password and Secret Key, it’s cryptographically impossible for anyone to read your data, even employees of 1Password. This is the strongest defense for protecting your data, but it also limits what’s possible when building new features that require server-side processing.

To address this problem, we built our confidential computing system, which allows us to extend our end-to-end encryption model into the cloud using specialized servers, called “enclaves”. These enclaves provide enforceable guarantees of isolation, confidentiality, and integrity through a cryptographic attestation system. This allows 1Password services to securely decrypt and process certain data on 1Password servers while maintaining the security and privacy guarantees you expect from 1Password.

Design principles

Our confidential computing system was designed around these core principles:

Verifiable guarantees: Security claims must be cryptographically provable. Enclaves must prove their identity and what code they’re running.
Public transparency: Every version of code deployed to our enclaves is published to a third-party transparency log. Anyone can audit what we’ve deployed, making it impossible for us to do anything in secret.
No operator access: Neither 1Password administrators nor administrators of our cloud provider can access code or data running inside an enclave. This is enforced at the hardware level, not by policy.
Trusted communication from clients: Our aim is for the enclave service to act as an extension of the 1Password apps running on your device. To connect to an enclave service, the clients must establish a trusted communication channel, which ties together attestation, signing, and encryption.

Foundation

Confidential computing is built on AWS Nitro Enclaves , which are specialized isolated virtual machines with their own kernel, memory, and CPUs. Enclaves are created by partitioning resources from a parent EC2 instance, with isolation enforced at the hardware level by the Nitro Hypervisor.

These are the key properties of Nitro Enclaves:

No external network connectivity and no persistent storage by default.
Memory isolation is enforced by hardware. No process, application, or user on the parent instance can access enclave memory.
No operator access or mechanism for any AWS operator to access enclave contents, verified by independent audit.
Cryptographic attestation where enclaves prove their identity and exactly what code they’re running by offering a signed attestation document.

Attestation

Attestation documents are generated by the Nitro Hypervisor and signed by AWS’s Nitro Attestation PKI . These documents include cryptographic hashes, known as PCRs, that uniquely identify what is running in the enclave:

PCR	Contents
PCR0	Hash of the enclave image (the exact code).
PCR1	Hash of the Linux kernel and bootstrap.
PCR2	Hash of the application.

By verifying an attestation document against AWS' published root certificate, 1Password clients can confirm they’re communicating with a genuine Nitro Enclave running specific, known code.

Trust principles

Traditional web applications depend solely on TLS for security, which places trust in the service operator. An operator, or an attacker who compromises them, could swap out server code at any time and even target specific users with no way for clients to detect it. 1Password confidential computing removes this trust requirement through a multi-layered verification system that clients perform before sending any sensitive data.

Release signing and transparency

Every enclave application release goes through a signing and publication process before deployment:

Signing: The release is signed using a 1Password-owned certificate, creating cryptographic proof that we produced this specific code.
Transparency logging: The signed release hash is published to Rekor , a public transparency log operated by The Linux Foundation as part of the Sigstore project. Rekor uses a Merkle tree structure to provide an append-only, tamper-evident record.
Attestation binding: The enclave’s PCR measurements are included in the signed payload, binding the release signature to specific attested code.

This provides several guarantees:

Verifiable authenticity: Clients can verify that enclave applications are authentic.
Public transparency: Every version ever deployed is recorded in an immutable ledger that we don’t control.
Independent auditability Anyone can inspect the log and verify our claims.
Non-targetability: It’s impossible to secretly target a specific user without compromising the entire system.

Verification resources

1Password root certificate

Our release signing uses a certificate chain. Each enclave application is signed by an application-specific end certificate, which chains to an intermediate certificate, which chains to the following root certificate:

Example Transparency Log Entry

The following is an example release payload for the Session Bridge service, released on November 12, 2025:

{"keyRingIds":[],"measurements":{"pcr0":"afad18031e4de6d0c3236a5b182d8d7531f09463e673ee35188824fded11503a784cc794bd2fb3e64d6a9622cfc0dc4a","pcr1":"745004eab9a0fb4a67973b261c6e7fa5418dc870292927591574385649338e54686cdeb659f3c6c2e72ba11aba2158a8","pcr2":"96ce51ff0fc2e462a0af13c008aaf6f8952f63fcff33a165b70d07d2c3e27fdbebc78d9a8c5e9b27797fd3a940f22224"},"serviceId":"session-bridge"}

The Rekor entry contains a SHA-256 hash of this payload.

View entry on Rekor.

You can independently search and verify any releases using the tools provided by Rekor.

Client verification flow

The root certificates for AWS Nitro, 1Password, and Rekor are hard-coded into our client applications, enabling offline verification without relying on network security.

Before trusting an enclave, clients verify:

The attestation document is validly signed by AWS’s Nitro PKI.
The release was signed by 1Password’s certificate chain.
The release was published to the Rekor transparency log.
The enclave’s PCR measurements match the signed release.

After all checks pass, the client establishes a secure communication channel. If any checks fail, the client will refuse to talk to the enclave.

Secure communication

We use the Noise protocol to establish encrypted channels between clients and enclaves. Specifically, we use Noise_NX_25519_ChaChaPoly_SHA256.

The attestation document ties everything together by including the enclave’s static public key. Since the document is signed by AWS’s Nitro PKI, clients can trust that the key genuinely belongs to the attested enclave. The client verifies that the key from attestation document matches the key used in the Noise handshake.

Session Bridge

All client requests flow through a single entry point called the Session Bridge, which is also an enclave service. The Session Bridge acts as a trusted deputy for the client. Requests follow these steps:

Clients verify the identity of the Session bridge, then establish a Noise session with it.
The Session Bridge attests and establishes secure channels to destination enclave services.
Requests are decrypted, re-encrypted for the destination service, and proxied securely.

This architecture means clients only need to perform attestation once, while the Session Bridge enclave handles trust verification for all upstream services using the same rigorous process the client does. Sessions are stored in an ephemeral, in-memory store within the Session Bridge enclave. They never persist to disk and cannot exit the enclave.

External communication and data storage

Nitro Enclaves have no network connectivity by default, which is a key property of their security. However, some enclave services need to communicate with external systems, whether to call third-party APIs or send data to databases for persistence.

Controlled external access

External communication is enabled through a SOCKS5 proxy running on the parent EC2 instance. Data must be explicitly passed through this boundary to leave the enclave. To further prevent unintended data exfiltration, this proxy enforces an allowlist of permitted destinations, ensuring enclaves can only connect to explicitly authorized hosts. Any connection attempt to an unlisted destination is rejected and logged.

TLS negotiation happens inside the enclave itself, with CA certificates bundled into the enclave image at build time. This makes sure the enclave, not the parent host or proxy, verifies the identity of external services.

Data protection for external storage

When enclave services need to send data externally for persistence, such as to a database, that data is encrypted with enclave-managed keys before leaving the secure boundary. This makes sure that even if an attacker gains access to the database, they cannot decrypt the contents. Only the specific enclave code that encrypted it can decrypt it.

Enclave key management

Some enclave services require long-lived cryptographic keys that persist across deployments. These keys allow the encryption and decryption of data stored externally, signing messages, or ensuring data integrity. Our system includes a secure key management system that maintains our no-operator-access guarantee.

Key generation and storage

Encryption keys are generated inside the enclave using secure random number generation. These keys never exist in plaintext outside the enclave boundary. To persist keys across enclave restarts and deployments, they are encrypted using AWS KMS before being stored externally.

AWS KMS integrates directly with Nitro Enclaves through attestation-based key policies. When an enclave requests to decrypt a key, it must provide its attestation document. KMS verifies this document and only releases the key material if the enclave’s PCR measurements match the policy to make sure only specific, attested enclave code can access the keys. Even with full access to our AWS account, an operator cannot decrypt enclave keys without running the correct code inside a genuine Nitro Enclave.

Secure version upgrades

When enclave code is updated, key access must transfer to the new version. This happens through an attested upgrade process:

The new enclave version is signed and published to the transparency log.
The outgoing version verifies the incoming version’s attestation and release signature.
After verification, the outgoing version grants the new version access to existing keys.

This makes sure there’s key access continuity across deployments while maintaining the guarantee that only verified 1Password code can access enclave-managed keys.

Secure development practices

Enclave applications are written exclusively in Rust, which we chose for its memory safety guarantees and compile-time checks. This prevents entire classes of vulnerabilities common in systems programming. We also use Rust for our client applications, which allows for us to use the same tried and tested libraries for important components such as cryptography and safe logging.

Log safety

Cloud-based enclaves present a unique challenge: Handling decrypted secrets while maintaining logs that are accessible to operators. We addressed this challenge with compile-time enforcement:

All logged types must implement a “loggable” trait that provides a safe-to-log representation.
Attempting to log non-loggable types causes a compile error.
Logs are exported through a custom OpenTelemetry collector that only accepts properly sanitized output.

This guarantees at compile time that sensitive data cannot accidentally leak through logs.

External validation

Our confidential computing system underwent an independent security audit in September 2024 , which affirmed the robustness of the design and found zero major vulnerabilities. The AWS Nitro System has also received independent verification of its confidential computing capabilities.

Learn more

Was this article helpful?

Glad to hear it! If you have anything you'd like to add, feel free to contact us.

Sorry to hear that. Please contact us if you'd like to provide more details.