Scytale
Enterprise
Turning an open-source identity engine into a product enterprises could actually run.
$ spire-server entry create \ -spiffeID spiffe://acme/billing \ -parentID spiffe://acme/node \ -selector k8s:ns:prod \ -selector k8s:sa:billing # repeat, by hand, for every service…
Enterprises had outrun their own security.
A single application was no longer one thing — it was dozens of interconnected services, owned by different teams, running across cloud, containers, and on-premise machines. Every service had to prove who it was to every other service. The perimeter-based tools built to handle that — firewalls, API gateways, Kerberos, OAuth — assumed a network edge that no longer existed.
66%
of IT executives were concerned about their service-authentication credentials.
83%
agreed their existing approaches couldn’t scale to a dynamic, hybrid-cloud strategy.
The industry’s answer was Zero Trust — and Scytale had already built its engine in SPIFFE & SPIRE. But it was almost entirely command-line-driven, the domain of a few engineers willing to hand-write YAML. Powerful, and stuck niche.
Remove the command line as the price of entry.
Wrap the raw capability of SPIFFE/SPIRE in a platform that let security teams retain full control and scale to thousands of identities — compressing application onboarding from weeks to minutes.
My users trusted the terminal and distrusted abstraction. The UI couldn’t just be prettier than the CLI — it had to be faster, clearer, and harder to break, while still respecting their expertise.
Turn an engine only experts could drive into a product an enterprise team could adopt.
Signal from where most teams don’t look.
I came in with no prior knowledge of the identity-security space — which was part of why I took it. Understanding came from a blend of sources, not one tidy research phase.
This was an early-stage startup racing to launch. We made a deliberate call: validate enough to design responsibly now, and formalize rigorous usability research post-launch, against a concrete product. Naming that tension is closer to what happened than pretending we ran a textbook program — and the roadmap wasn’t lip service. Under HPE, it became a documented set of research OKRs.
Who I was designing for.
Simeon · Security Engineer
Needs to automate security tasks and delegate — so he stops being the bottleneck every team routes through, while keeping security consistent across distributed teams.
Owen · DevOps Engineer
Needs a platform that scales and slots into his existing toolchain — Kubernetes, Docker, cloud infra — without forcing development to a crawl.
Deepti · Software Developer
Wants a low-risk, self-service way to integrate security that doesn’t disrupt her development cycle.
The questions that drove the work.
One coherent system, built surface by surface.
Because I was building the product’s entire surface, the work was a set of interlocking features that had to feel like one system. A few were pivotal — and an extensible design system underneath is what let one designer keep them consistent and iterate fast.
Card-based, and built for scale from day one.
Its DNA came from a conversation with our front-end engineer, who wanted Material Design for launch speed — so I designed with that framework, a modular card layout, but pushed the cards well past the defaults.
I deliberately left room on each card for more than it currently held, and built every section to accept pagination and search— because the real test wasn’t the demo dataset, it was the screen at enterprise scale. Identity-provider cards, node sets grouped by hosting environment, and a Scytale Servers table with IP, version, last-accessed and health — all under a trust-domain switcher.
Automating the initial CLI setup into the UI would have added months. I kept setup on the command line and focused the UI on the creation and maintenance work users did every day — setup flagged for later.
One model, protecting users from themselves.
A workload maps an identity to a set of selectors— Kubernetes namespace, pod UID, pod label, container name, Docker image — all tied to a SPIFFE ID and TTL. Early on we’d considered letting users set every parameter freely, with no guardrails. In practice that was cumbersome and dangerously error-prone: a wrong value could break an entire system.
So I moved to a guided approach that surfaced the right data up front for each type — and got the destructive actions right, separating disable (a reversible pause) from delete, since deleting a policy stops matching workloads from retrieving their SVIDs.
The “purpose-built” hypothesis, tested.
A node set describes a hosting environment — a scaling collection of instances — and each type carried genuinely different parameters behind the same task: Kubernetes (SAT and PSAT), single and multi-node AWS EC2, Linux X.509 and Join Token, and a fully custom selector type.
I designed one consistent, form-driven interaction model and adapted it across every type — reusing the workload-creation framework for node sets to keep the UI coherent. Deletion is dependency-aware: you remove a node set’s workloads before you can remove the node. To future-proof it, I worked with the open-source team to get a table of every selector data set, so the framework would hold for whatever we added later.
From a demo feature to a platform.
Identity mapping gives cloud workloads access to on-premise identity providers like Active Directory. I first designed it for 1:1 mapping — one identity at a time, entered individually.
Pressure-testing it against real enterprise scale, it became obvious that model would collapse the moment a team had thousands of identities. So I redesigned it around one-to-many mapping.
Built to expand before the roles existed.
Administrators needed to add many users across multiple trust domains within one enterprise instance, with role-based permissions on each. I looked to how AWS and Google handle user management as reference points, and designed for both 1:1 and one-to-many role assignment from the start.
The catch: the actual user roles weren’t defined when I began. Rather than wait, I built the UI to be expandable— able to absorb whatever roles the product team eventually settled on — so design didn’t block on a spec still in flight.
One filterable view — a call I made and defended.
The team was split: separate log views per event type, or one unified view with filtering. As the UX lead I made the call — a single view with filtering by type (system events, user events, and so on), because it was the better overall experience and matched the mental model users already had from tools like Google’s.
I audited comparable event logs to sanity-check the pattern, then committed to it. Rounding out the platform were the connective pieces — account management, domain switching, empty states, clear error placement — the unglamorous surfaces that decide whether a product feels trustworthy.
The proof of concept, formalized into HPE.
This was high-level proof-of-concept work, running on a limited basis before the acquisition. When HPE acquired Scytale, the UI I’d designed was formalized and integrated into HPE’s product offerings — the same flows, re-skinned into the HPE Design System (HPE green, the element logo, Metric type, Grommet components). The bones held; the brand changed.
POC (Scytale) → HPE-formalized
An engine, turned into an acquisition.
Manual CLI setup and hand-written YAML replaced with a self-service UI — without compromising existing security controls.
The platform was pivotal in Scytale’s acquisition by Hewlett Packard Enterprise. It lives on today as HPE Project Cosigno, folded into HPE’s Zero Trust strategy.
Manual CLI setup · slow identity mapping via YAML · low adoption of SPIRE, stuck with the few willing to run it.
Self-service UI · real-time, UI-based identity assignments · successful enterprise trials and a feedback loop that drove adoption.
What I carried out of this.
A demo-proof design can still fail in production.
Shipping the 1:1 identity mapping would have worked in a demo and failed at scale. Only user reality — not aesthetics — tells you which one you actually have.
Words matter, and so does taking a position.
We spent days deadlocked on a single word — “cluster” vs “node set.” And on event logs I learned to lead, not just facilitate: being hired as the expert means taking and defending a call.
A command-line engine, turned into a product an enterprise could run — and HPE wanted to buy.
The strongest solutions don’t just tame technical complexity — they reduce friction, empower the person on the other side of the screen, and make an intimidating system feel like something you can actually run.