Context
What is a secret?
A secret is any sensitive data that must be protected and only accessible by authorized systems or individuals. They are used to manually configure systems, troubleshoot, or perform privileged actions.
User goal
Users want a secure, centralized way to manage secrets while ensuring that only the right people have access to them.
Research
Accommodating our tool for two types of personas
Since many internal Okta employees had prior experience with secrets management, I partnered with my PM to set up exploratory interviews. Our goal was to better understand their workflows, pain points, and how needs varied across different personas.
Developer
Problem
Secrets are stored all over the place (code repositories, spreadsheets, multiple password managers)
Wants a unified solution to store and generate strong random secrets
“We’re storing secrets in GitHub, Confluence, even Slack sometimes. It’s all over the place.”
Security admin
Problem
Too many people had too much access
No visibility or audit trail
“It’s hard to prove to auditors that we’re compliant when we don’t have a clear record of who accessed what secret and when. We need better visibility and traceability to meet security requirements.”
Design challenge
How might we help developers and security teams securely create, manage, and access secrets?
After aligning on the core user problems and opportunity areas, we translated them into a design challenge that would guide the team’s direction.
This question grounded our exploration across these principles:
Security by default – Avoid risky behaviors like plaintext storage or weak secrets.
Least privilege access – Ensure users only see secrets they are entitled to.
MVP scoping
We chose to support generic key-value pairs as the foundation for the MVP.
Instead, I designed the system to be extensible, so additional secret types could be layered in later without requiring major changes to the core experience.
Success metrics
We came up with metrics to improve usability and increase adoption.
To align the team and measure impact, we defined a set of product and UX success metrics:
Goal Metric
Reduce security risk → % of secrets with audit log enabled
Improve usability → Task completion rate for creating and retrieving a secret
Increase adoption → # of secrets creating in the first 30 days after launch
Reusing existing patterns
To ensure consistency, I leveraged existing policy creation flows from Okta’s ecosystem.
While exploring design options for policy creation, I prioritized consistency across Okta’s ecosystem to reduce cognitive load and improve usability. I conducted a comparative analysis of existing policy flows across products like Access Policies and App Sign-On Policies. Users wanted our policies to have a similar experience to existing policies within Okta.
User testing & validation
Users appreciated that secret values were hidden by default but were caught off guard when certain actions were restricted.
We ran moderated usability tests with 10 participants, focused on validating secret creation, access control, and auditing workflows.
Final solutions
Behind the Vault: Designing a Secure Secrets Experience
Generate and store secrets in one place
Users can create a generic secret by specifying key value pairs or generate a strong secret value.
Customer benefit:
This allows users to securely generate and store secrets in a unified tool reducing reliance on insecure storage methods.
Reveal secret value with approval workflow & MFA
When a user tries to view a secret’s value, they may need to satisfy multi-factor authentication (MFA) and approval requirements based on policy.
Customer benefit:
This ensures that certain actions are guarded behind extra authentication, reducing risk of unauthorized access.
Define permissions and access controls via policy
Admins can define fine-grained access policies controlling who, what and for how long users take actions on secrets.
Customer benefit:
This enforces least privilege which limits access rights to only what’s necessary for specific tasks.
Audit who accesses what secret and when
Admins can view an audit log that displays access events that includes user, specific action performed, guardrails, and timestamp.
Customer benefit:
This gives users full visibility into secret creation and usage, enabling them to detect unauthorized access and meet compliance requirements.
Outcome
Users onboarded quickly and felt more confident using our secrets manager.
We launched the first version of Okta Secret Management as part of our beta release with select customers. Our goals were to validate the core value, reduce security risk, and gauge adoption across developer and security teams.
Outcomes:
