Thales Quorum Approval
Designing a secure and traceable multi-party approval experience for high-risk cryptographic operations
01OVERVIEW
Designing multi-party governance for high-risk cryptographic operations
DPoD is Thales’ cloud-based platform for deploying and managing cryptographic services that help organizations protect sensitive data and encryption keys. As enterprise security and compliance requirements grew, customers needed stronger governance over high-risk operations that could still be performed by a single authorized user.
I led the end-to-end design of Quorum, a 0→1 governance capability spanning policy configuration, request submission, multi-party approval, execution, and audit history. Working closely with product and engineering, I helped shape the governance model, simplify its configuration, and design the cross-role experience from concept through validation and launch.
A global, operation-based governance layer that adds multi-party approval to selected high-risk operations without taking users out of their existing DPoD workflows.
02THE PROBLEM
Authorization alone wasn't enough
DPoD used role-based permissions to control which operations users could access. Depending on their role, multiple authorized users could have permission to perform the same sensitive action.
The risk was that authorization still allowed any one of those users to complete a high-impact operation independently. For actions such as deleting a cryptographic service, customers needed an additional layer of governance before execution.
03CUSTOMER RESEARCH
Customers wanted stronger governance without more complexity
Early enterprise customer interviews helped us understand what stronger governance needed to accomplish. Across customers, three needs consistently surfaced: prevent a single person from independently completing sensitive actions, keep approval inside DPoD, and maintain a traceable record of every decision.
04INITIAL DIRECTION
Our first model offered granular control—but required too much setup
Our initial concept applied Quorum at the service level. Administrators first selected a cryptographic service, chose which operations required Quorum, and assigned the appropriate approver group.
This provided precise control, but the same setup had to be repeated for every service. As customers managed more services, maintaining similar policies would require more time and repetitive administrative work.
How might we reduce configuration effort without compromising governance?
05CUSTOMER RESEARCH & TURNING POINT
Customer research pushed us toward a simpler global model
Testing the service-level prototype with major enterprise customers revealed a clear tension: they valued Quorum’s security, but not the repeated setup required across individual services. They wanted governance to be simpler and more predictable to manage.
I worked with Product Managers, the Design Team, and Engineering to evaluate the trade-off between simplifying the experience and preserving meaningful governance.
We removed service-level configuration and moved to a global, operation-based model: administrators choose which high-risk operations require Quorum, and the policy then applies consistently across services.
06EXPERIENCE ARCHITECTURE
One governance workflow, three roles
With the governance model established, the next challenge was designing for three roles with different responsibilities.
07KEY UX DECISIONS
Designing one connected experience across three roles
I designed each role around the same protected operation while tailoring the interface to what each user needed to configure, understand, and do next.
01 · Administrator
Configure protection once, not service by service
Administrators configure Quorum around selected high-risk operations rather than individual services. Once enabled, the policy applies consistently across all services, eliminating repeated configuration.
Design decisionCentralize policy configuration
02 · Requester
Turn a risky action into an approval request without losing context
Previously, an authorized requester could confirm a high-risk operation and execute it immediately. With Quorum enabled, the same action becomes a request for approval while keeping the affected service and operation visible.
Design decisionKeep approval in context
03 · Approver
Give approvers the context to decide—and requesters the visibility to follow up
Approvers see the requester, affected service, protected operation, and the controls they need to approve or reject. Requesters see the same request from a progress perspective, including who has responded and who is still pending.
Design decisionMake progress actionable
Why a list view? A list supports fast scanning across multiple Quorum requests, making it easier to compare status, identify what needs attention, and manage requests at scale.
08TESTING & ITERATION
Testing refined both policy flexibility and approval visibility
Prototype testing revealed two areas where the experience needed to adapt to real-world governance workflows.
01 · Adaptability
Make policies adaptable as governance needs change
The initial prototype allowed administrators to enable or disable a policy, but not edit its configuration. Internal stakeholder testing showed that governance requirements could change over time.
Requiring administrators to disable and recreate a policy would introduce unnecessary maintenance work, so I added an Edit Policy flow that allowed configuration to evolve without rebuilding the policy from scratch.
02 · Actionability
Turn approval progress from a number into a next step
The early prototype summarized progress as 2 of 3 approvals received. Testing showed that this answered how many approvals were missing—but not who was still blocking the request.
I replaced the aggregate-only status with named approvers and individual states, allowing requesters to identify who had not responded and follow up directly.
Aggregate progress only
Users could see that one approval was missing, but not who was blocking the request.
Named approvers + individual status
Progress became actionable, not just visible.
09IMPACT
A simpler model created a foundation that could scale
The simplified operation-level model gave Quorum a scalable foundation. After launch, the capability expanded from four protected operations in the initial release to more than 20, extending multi-party governance across a broader range of high-risk workflows.
Three months after release, a DPoD customer survey included specific questions about the Quorum experience. 92% of respondents to the Quorum satisfaction question reported being satisfied with the feature. Among surveyed Quorum users, 73% indicated an intention to renew DPoD, providing an additional positive customer signal after launch.
→WHAT I LEARNED
The goal isn't maximum flexibility. It's the right level of flexibility.
We started with a highly configurable service-level model, but customer research showed that granular control can become operational overhead when it creates repeated work without adding enough value.
The final model simplified configuration while preserving flexibility where it mattered: choosing which operations to protect, adapting policies as governance needs changed, and giving users actionable approval visibility.
If I continued the work, I would instrument approval completion time, request expiration and abandonment, and policy-edit behavior to better understand Quorum's operational impact at scale.
