Automating user provisioning sounds simple, until you remember everything that provisioning really touches.
For most SaaS products, SCIM is “just” user and group lifecycle management. Your identity provider calls an API, accounts get created, access is assigned, and offboarding removes it. But for 1Password, provisioning intersects with something far more sensitive: the cryptographic foundation that protects every vault.
1Password is end-to-end encrypted by design. We do not hold your encryption keys and cannot see your vault contents. This provides a powerful guarantee that even if 1Password’s servers were to be compromised, your data would remain unreadable, as the keys required to decrypt it are never accessible to us.
That model is why customers trust 1Password with their most sensitive credentials, but it also makes automation genuinely hard. After all, how can we automate provisioning inside a zero-knowledge platform, without reintroducing trust in the server?
That is the problem Automated Provisioning hosted by 1Password solves, and it’s why our approach is fundamentally different from other provisioning options on the market.
Most hosted provisioning solutions are built on a straightforward assumption: the service performing provisioning can be trusted to manage the system state, distribute keys, and act as an authority. This is what makes many SCIM implementations “easy” to host, but that assumption quickly breaks down in a zero-knowledge system.
If a server can create, hand out, or swap cryptographic keys without independent verification, then clients are ultimately trusting the server as a source of truth. Even if the threat is theoretical, the trust model is real, and even a theoretical gap matters for 1Password.
Public key cryptography is built around two keys: a private key that must remain secret, and a public key that can be shared freely.
When you share something securely, you encrypt it using the recipient’s public key, and only their private key can decrypt it. The difficulty comes in ensuring that the public key received actually belongs to the person in question.
In most systems, the server is meant to be the source of truth. However, it’s entirely possible that a malicious or compromised server could be used to swap in a fake public key and trick a user into encrypting data to be shared with an attacker instead of the intended recipient. The attacker could decrypt it, read it, then re-encrypt it for the real recipient so everything still “works.”
However theoretical that threat may be, for a product built on the principle of not requiring trust in our servers, we wanted to eliminate the risk as completely as possible.
Public Key Verification (PKV) is our answer to this threat. PKV gives every 1Password client the ability to independently verify that a public key belongs to its intended owner, and it’s powered by a new foundation called the Account Trust Log.
The Account Trust Log works as a cryptographically verifiable history of an account’s keys and trust decisions:
Every time a key is created or updated, that event is recorded as a new entry
Each entry includes the operation performed, a hash representing the account’s “world state,” and a cryptographic signature from an authorized actor
Each entry links to the previous entry, forming a tamper-evident chain
If a link is altered, the chain breaks and tampering is detectable
Now, clients and admins can verify key authenticity against the Trust Log, meaning that 1Password clients don’t have to trust our servers alone to distribute public keys correctly, and our servers can’t be used even theoretically to compromise public keys.
This marks a meaningful shift in our security model, and an essential step toward enabling automation at scale.
Historically, the way to preserve zero-knowledge and still support automated provisioning was to push sensitive operations into customer-controlled infrastructure. In 1Password, provisioning is tied to the creation and management of key material that enables secure access to encrypted vaults. This is why we built the 1Password SCIM Bridge, a self-hosted service that lives inside client environments and keeps sensitive cryptographic operations isolated from 1Password.
Unfortunately, 1Password SCIM Bridge can also come with real operational costs, and customers told us they wanted the same privacy guarantees without having to own the operational burden.
End-to-end encryption creates a paradox when it comes to letting 1Password EPM do more for clients, since it can see so little of their data.
Automated Provisioning hosted by 1Password resolves that paradox by moving provisioning’s sensitive cryptographic operations into an isolated execution environment built on confidential computing and using secure enclaves, which exists inside of 1Password’s infrastructure, .
In plain terms, the team at 1Password have built a hosted provisioning system where cryptographic operations can be performed. The secrets involved cannot be accessed, inspected, or extracted by 1Password, cloud operators, or anyone with privileged access to the surrounding infrastructure. This is a new architecture designed specifically for automation in a zero-knowledge system.
At the heart of Automated Provisioning hosted by 1Password is the secure enclave, an isolated compute environment designed to keep sensitive data protected even while it’s being used.
The enclave can perform cryptographic operations needed for provisioning, like generating encrypted key material and preparing account setup flows, but it cannot reveal those secrets to any outside party. For this to work, we also need strong proof that the enclave is running the exact code we intend, and that the rules we designed cannot be silently bypassed.
That is where attestation comes in. Before clients or services trust the enclave, they verify a cryptographic attestation measurement proving the enclave is running the expected, audited code. This makes the environment verifiable, not just isolated.
Automated Provisioning hosted by 1Password is the first major 1Password feature that brings together:
Confidential computing for operator-inaccessible cryptographic execution
Public Key Verification for client-side verification of key authenticity
The Account Trust Log for a tamper-evident, signed chain of trust
This combination is the core differentiator, and it’s the reason 1Password can host provisioning successfully.
When your identity provider provisions a new user, this initiates a secure sequence:
Your IdP makes a standard SCIM request to 1Password
The request is processed inside the enclave
Key material is generated and sealed, protected inside the enclave’s boundary
The operation is recorded in the Account Trust Log as a signed entry
The user completes a secure confirmation flow, ensuring only the intended user can activate and claim access
From there, clients can at any time independently verify keys and changes via PKV and the Trust Log.
Essentially, behind every “add user” action, many cryptographic operations are performed in isolation, recorded in a verifiable history, and designed so that no operator can tamper with or inspect the sensitive parts of the process.
One of the most important design choices we made at 1Password is that Automated Provisioning does not rely on implicit server authority. To enable Automated Provisioning hosted by 1Password, an administrator must explicitly delegate trust to the enclave using a service account, so that it can perform specific actions and write the appropriate entries into the Trust Log. This ensures that automation always remains rooted in an admin’s deliberate, verifiable action, not in “the server can do whatever it wants.”
Automation at scale must assume real-world failure modes, including identity provider compromise and misconfiguration. Automated Provisioning hosted by 1Password includes guardrails designed to reduce blast radius and prevent abuse, including:
Trusted email domains, cryptographically signed during setup to block rogue invitations
Scoped provisioning controls, so certain critical groups cannot be automatically managed
Attested environments, so provisioning actions occur only inside verified enclave code
Operator-inaccessible execution, reducing the risk of tampering or inspection
If you already use SCIM elsewhere, it can be tempting to view provisioning as a solved problem. But in a zero-knowledge platform, hosted provisioning isn’t just a matter of integration; it requires essential decisions about security architecture
Automated Provisioning hosted by 1Password is different because it does not ask you to trade privacy for automation. It preserves end-to-end encryption and removes the operational burden of self-hosting by combining:
Confidential computing for isolation and operator-inaccessibility
Verifiable cryptography through PKV and the Account Trust Log
Admin-rooted delegation so automation is accountable and constrained
Most provisioning solutions focus on simplicity by relying on an assumption of centralized trust. We instead committed to building simplicity without centralizing trust.
The key takeaway is that Automated Provisioning hosted by 1Password removes the need to deploy and maintain a SCIM Bridge. Cryptographic operations run inside an isolated, attested secure enclave, and Public Key Verification and the Account Trust Log make key authenticity independently verifiable. Secure automation is made possible by ensuring that it’s kept constrained and accountable through explicit delegation, not server authority.
The result is provisioning that scales without compromising the zero-knowledge model.
Automated Provisioning hosted by 1Password, multi-tenancy, and the Users API for Partners, were all made to serve the same goal; they make it easier than ever to deploy 1Password EPM wall to wall. Simplified provisioning, scalable structure, and predictable governance all help enterprises secure every team and workflow, while preserving the usability and zero-knowledge security model that 1Password is known for.
These capabilities mark another step toward what modern enterprises need most: security that scales with the business instead of slowing it down.
此内容由惯性聚合(RSS阅读器)自动聚合整理，仅供阅读参考。 原文来自 — 版权归原作者所有。