Overview
As the superannuation industry becomes a growing target for fraud and scams, funds need to strengthen their authentication experiences. Technology such as email authentication is no longer fit for purpose.
UniSuper decided it was time to phase out email as an authentication factor, replacing it with passkeys.
Company
UniSuper
The team
Product owner
Business analyst
Vendor specialists
Developers
Year
2024-25
At a glance
Here's a quick summary of the project.
Problem
Industry a growing target for fraud and scams
Email authentication vulnerable.
Solution
Phase out email authentication
Introduce a new, more secure authentication factor.
Outcomes
Introduce passkeys to members
28k+ passkeys enrolled (FY26)
70k+ verified passkey logins (FY26)
Key member cohorts transitioned away from email factor
Authentication design system created.
My role
I was the sole UX designer on the project team. As this was a highly technical 'buy not build' project, with vendor engagement, it meant working within significant constraints.
I was responsible for advocating for the member experience when assessing technology options. During the design and build phase I owned experience and design decisions wherever possible. When constraints impacted experience, I would present, influence and make the case for the vendor to make customisations.
Throughout the project I collaborated closely with the product owner, business analyst, and vendor specialists.
Decisions that mattered
Assessing technology options
We knew the business wanted to phase out email, but the new authentication factor to introduce was undecided. As a project team we entered a technology assessment phase. We assessed potential new factors for security strength, complexity to build, experience and support. I was responsible for assessing the experience.
I mapped the factor experiences across three key flows:
First log in (after registration) - include factor set up
Next log in - how the member would use the factor
Subsequent log ins - how the factor would change behaviour.
These flows highlighted pros, cons and pain points. We were then able to overlay the security assessment on top of the experience, which highlighted scenarios such as members that live overseas.
From an experience perspective there was no clear stand out. Each factor could work, but the experience needed to be considered alongside the other assessment factors. Trade-offs would need to be made.
Ultimately, a decision was made to move forward with passkeys as the new authentication factor. Passkeys provided best in class security and ease of use (once set up). Pain points from the experience assessment and member knowledge of the technology would need to be addressed in the design phase.
Overview of experience assessment flows
Building an authentication design system
As we exited the tech assessment phase, my next step was to deep dive into the vendor platform, and how passkeys would fit into it. Through close collaboration with the vendor I was able to map out the key steps of the experience, and understand the scale of constraints. At this point I could foresee future risk - two other projects were due to fast follow and implement the vendor technology for the employer and adviser platforms. The project teams were stretched, timelines were tight, and they would not have the same level of vendor engagement.
That's when I decided to build an authentication design system. By taking the time to create the system I could embed my knowledge into a single source of truth, de-risk design, and unblock other projects.
To speed up creation I used primitives and components from the existing UniSuper design system as building blocks, only creating new components as required. This allowed me to focus, while knowing everything would be on brand by default.
I went through the vendor platform step by step, creating components that captured scenarios, states and edge cases. I prioritised by release, ensuring time was spent creating value for developers. I was able to identify components that would require customisation for the other platforms, so I created placeholders variants, that other designers would be able to edit.
When onboarding other designers into the system I was able to point out what they could customise, while emphasising reuse where possible. They should not need to make any major edits beyond content, links, etc. If they found a new use case we could extend the system.
The other designers were able to take the vast majority of screens and flows into their own projects, saving time and effort. This kept their projects on track for delivery.
Advocating for consistency
The design system enforced consistency at an experience level, but there was another key area of consistency to consider - authentication factors.
Our project had laid the foundation for the vendor platform and passkey usage, which other projects could use. The challenge came when other projects believed their context required different authentication factors. This would cause fragmentation of authentication factors, which in time would be costly to maintain and support.
I discussed this with my product owner. We decided to engage the other project product owners to make the case for avoiding fragmentation. We used the design system as the guide for consistency, emphasising the ease of updates for all platforms in the future (UI, content, tech) if the authentication factors remained aligned. They could see the value in this, and would advocate for consistency moving forward.
This alignment allowed the product owners to push back when other project stakeholders wanted to have different authentication factors.
The below images are examples of the design system
Refining details
Uplifting the passkey experience
Unfortunately, the passkey experience came with major technical constraints.
This meant key pain points, such as setup failure, could not be improved through design changes. This was a concern, as passkeys would be a new technology to the vast majority of members.
We had to rely on content to try ease friction in the experience. We raised the need for detailed help guides to assist members who would experience these pain points. This is the reality of 'buy not build' projects.
Passkeys for existing members
The initial scope of passkeys was to release to new members, as part of the account set up. This was seen as controlled roll out of the factor, but would impact uptake. The product owner wanted to deliver an experience for existing members, but a key piece of vendor technology was not ready at the time.
I took this as an opportunity to design an MVP experience that existing members could use within member online. Simplicity was key, as we were nearing the release deadline. I designed an experience that linked members out to the vendor platform, enrolled a passkey, then returned to member online. They could then see their enrolled passkey, and have the ability to remove it.
The project tech lead was able to create a proof of concept, which was then implemented. This allowed us to offer passkeys to existing members, delivering value for the business.
Example of passkey section within member online
Example of an enrolled passkey within member online
Example of removing a passkey from member online
Outcomes
Passkeys were rolled out to member cohorts in phases, to support member transition. Passkeys were rolled to all members in February 2026.
Highlights since the rollout include:
28k+ passkeys enrolled (FY26)
70k+ verified passkey logins (FY26)
Key member cohorts transitioned away from email factor.
Passkeys have positioned UniSuper as a leader in security in the superannuation industry. Member feedback has echoed that leadership position directly, crediting the fund for taking a security-centric approach.
The authentication design system helped deliver improved authentication experiences across three platforms.
The below GIF showcases the passkey log in experience
Learnings
Design system driving efficiency
The design system work on this project has changed my workflow. Time consuming to set up, but the efficiency gains in speed, consistency, scalability and maintenance can't be ignored.
I now build in time to create a local system on projects and features, so I can have these benefits. I'm spending less time updating and maintaining dense design documentation. My designs can scale, and team mates can reuse components in their work where relevant.
This approach also shines when collaborating with a content resource. What used to be a slow, dependency heavy collaboration now gives the content resource agency. I set up master components, tell them where to update, they update, and everything flows through the designs.