Product Management
iOS and Android
Enterprise Identity
Product Design
Enterprise Authenticator App Case Study
Advancing a native authenticator app for enterprise security.
I led the product evolution of a native iOS and Android authenticator application used to complete secure sign-in, multi-factor authentication, and passwordless experiences.
The work extended beyond modernizing the interface. We needed to help people make better security decisions, give enterprise administrators greater control over authentication behavior, and maintain a dependable experience across different devices, operating systems, and deployment environments.
The result was a clearer and more capable authenticator experience that supported push authentication, one-time passwords, number challenge, device registration, and policy-driven security journeys.
Key Facts
Native
iOS and Android authenticator applications
5 methods
Push, one-time passwords, number challenge, registration, and policy journeys
Policy-driven
Administrators control which methods apply and when
Enterprise beta
Validated with enterprise customers and internal testers
This native iOS and Android authenticator app supports five authentication methods, including push, one-time passwords, and number challenge, with policy-driven controls validated in an enterprise beta.
The Challenge
Authentication happens in a small moment, but a poor decision carries real consequences.
When an approval request appears on a phone, the person receiving it needs to understand what is happening, whether the request is legitimate, and what action to take. If the information is unclear, users may reject valid requests, approve suspicious ones, or turn to support for help.
The existing application provided the required authentication capabilities, but several parts of the experience needed to evolve:
- Important approval decisions lacked enough context.
- Device registration and recovery flows could be difficult to understand.
- Enterprise customers needed more control over the authentication methods used in different situations.
- The experience needed to support emerging passwordless and step-up authentication journeys.
- iOS and Android required different technical and interaction considerations.
- Android fragmentation affected notifications, background processing, battery behavior, and overall reliability.
This was not simply a visual redesign. It was a security, platform, and product experience challenge.
What Success Needed to Look Like
Easier to understand, without weakening the security decisions built into the experience.
Success meant finding the right balance across four product outcomes.
Clearer for users
People needed enough context to recognize a legitimate request, understand the required action, and recover when something went wrong.
More flexible for enterprises
Administrators needed to control which authentication methods were available and when stronger verification should be required.
Dependable across platforms
The core experience needed to remain consistent while respecting native iOS and Android behaviors, technical constraints, and interaction patterns.
Ready to evolve
The product needed a foundation that could support additional authentication methods and changing enterprise security requirements over time.
My Role
Product leadership across discovery, definition, and delivery.
At the time, as Product Manager, I led the work across discovery, product definition, prioritization, validation, and delivery. My responsibilities included:
- Defining the product direction and expected behavior across registration and authentication journeys
- Translating enterprise security requirements into understandable product flows
- Prioritizing improvements across push authentication, number challenge, one-time passwords, registration, and error handling
- Aligning mobile engineering, product design, QA, security architecture, SDK, documentation, and support teams
- Managing backlog refinement, sprint priorities, product decisions, and release readiness
- Coordinating beta validation with enterprise customers and internal testers
- Using feedback and device-level findings to refine the experience before broader rollout
A central part of my role was connecting perspectives that did not always begin in the same place. Security teams focused on assurance, administrators focused on policy control, mobile teams focused on platform behavior, and users simply wanted to sign in without confusion.
The product direction had to make those needs work together.
Product Approach
Designing the authenticator as part of a larger identity system.
Understand the complete authentication journey
The mobile application was only one part of a larger identity system.
A user might begin on a website, receive a notification on a phone, open the authenticator, complete a verification step, and then return to the original experience. Registration could begin through a QR code, an activation link, or an enterprise-guided setup process.
Looking at the mobile screens in isolation would have missed important points of friction.
I reviewed the full journey across:
- Device registration and activation
- Push-notification delivery
- Request review and approval
- Number challenge verification
- One-time password generation
- Expired or interrupted sessions
- Failed registration attempts
- Device and operating-system permissions
- Enterprise policy configuration
This broader view helped the team identify where users lost context and where the product needed clearer transitions, feedback, or recovery options.
Design for informed security decisions
The most important product principle was simple: authentication should be fast, but it should not be careless.
A generic approval screen may reduce friction, but it can also encourage users to approve requests without thinking. The product needed to make the decision understandable without turning every sign-in into a complicated security exercise.
We improved the experience around three questions:
- What is requesting access?
- Is this request expected?
- What should the user do next?
Push-approval experiences were structured to present clearer information, stronger action hierarchy, and more intentional confirmation states.
The objective was not to add more information everywhere. It was to provide the right information at the moment it could influence a security decision.
Introduce stronger verification through number challenge
Push authentication is convenient, but repeated or unexpected approval prompts can create risk. Users may approve a request out of habit or simply to make the notification disappear.
Number challenge added an additional verification step.
During sign-in, the user was shown a number in the requesting experience. The authenticator then required the user to select or confirm the corresponding number before approving access.
This created a stronger connection between the sign-in attempt and the mobile approval. It also made accidental or inattentive approvals less likely because the user had to actively verify the request.
The product challenge was to introduce this stronger security step without making it difficult to understand. The instructions, available choices, confirmation feedback, expiration behavior, and failure states all needed to work as one coherent flow.
Simplify device registration
Authentication cannot work reliably if device registration is confusing or incomplete.
The registration experience needed to support different enterprise environments while guiding users through the required setup steps. Depending on the customer journey, a user could register through QR-code scanning or a link-based activation flow.
We focused on making registration more understandable by improving:
- The explanation of what the user was registering
- Camera and notification permission guidance
- Progress and completion feedback
- Expired activation messages
- Retry and recovery paths
- Confirmation that the device was ready for authentication
These details were important because registration problems often appear to users as authentication failures. Clearer setup and recovery reduced uncertainty before the first sign-in request was ever received.
Support enterprise policy without exposing its complexity
Different organizations have different security requirements. Even within one organization, the appropriate authentication method may depend on the user, application, risk level, or point in the journey.
The app therefore needed to support policy-driven behavior.
Enterprise administrators could determine which methods were available and when additional assurance was required. The application then needed to present the appropriate interaction without requiring the user to understand the underlying policy logic.
This allowed the platform to support scenarios such as:
- Lower-friction approval for routine access
- Number challenge when stronger confidence was required
- One-time passwords for supported environments or recovery scenarios
- Step-up verification for higher-risk actions
- Different authentication options for specific users or journeys
The product value came from separating administrative flexibility from end-user complexity. Enterprises gained control, while users received an experience appropriate to the situation.
Respect the differences between iOS and Android
Consistency did not mean making both applications behave identically.
iOS and Android have different conventions for navigation, permissions, notifications, background processing, and device security. Android also introduced additional variability across device manufacturers and operating-system versions.
The product direction established consistent principles and expected outcomes while allowing each platform to use appropriate native patterns.
Areas requiring particular attention included:
- Notification delivery and handling
- Background-process restrictions
- Battery optimization behavior
- Camera permissions for QR registration
- Biometric capabilities
- Application lifecycle and session recovery
- Accessibility and native interaction patterns
- Device-specific error conditions
This approach helped the product feel cohesive without forcing one platform’s behavior onto the other.
Validation and Delivery
Beta testing in real enterprise environments.
Authentication products have little tolerance for ambiguity or unreliable behavior. A flow that works in a controlled test environment may behave differently across customer configurations, device models, operating-system versions, and notification settings.
I coordinated beta testing with enterprise customers and internal teams to evaluate:
- Registration success
- Push-notification delivery
- Approval and denial behavior
- Number challenge comprehension
- One-time password access
- Policy-driven method selection
- Expired and interrupted requests
- Android device reliability
- Error messaging and recovery
The beta program was not treated as a final approval checkpoint. It was a learning phase that helped us find real-world issues before broader release.
Feedback revealed places where users hesitated, misunderstood instructions, or needed clearer recovery guidance. It also helped the team uncover platform and device-specific behaviors that were difficult to reproduce through standard testing alone.
Cross-Functional Execution
Keeping security, design, and engineering aligned around shared outcomes.
The work required coordination across several product and technical areas.
Mobile engineers were responsible for reliable native behavior. Security architects helped define assurance requirements. Designers translated complex security interactions into understandable experiences. QA needed to test a large combination of policies, devices, platforms, and user states. SDK and platform teams ensured that mobile behavior aligned with the wider authentication journey.
I kept these groups aligned around shared product outcomes:
- Users should understand the decision they are making.
- Administrators should be able to apply the appropriate security policy.
- Each authentication method should behave predictably.
- Failures should be understandable and recoverable.
- Platform differences should not create inconsistent security outcomes.
This outcome-based alignment helped the team make decisions when usability, security, and implementation constraints competed with one another.
Outcome and Impact
From a functional mobile utility to an adaptable part of enterprise authentication.
The work advanced the authenticator from a functional mobile utility into a clearer and more adaptable part of the enterprise authentication experience.
Key outcomes included:
Stronger authentication options
Number challenge added a more deliberate verification method for situations requiring greater confidence than a basic approval prompt.
Clearer registration and approval journeys
Improved instructions, contextual information, feedback, and recovery states helped users understand what was happening throughout the authentication process.
Greater enterprise flexibility
Policy-driven behavior allowed organizations to apply different authentication methods based on their security needs without transferring that complexity to the user.
A more consistent native experience
The redesigned applications followed appropriate iOS and Android interaction patterns while maintaining consistent product principles and security outcomes.
Better real-world readiness
Enterprise beta testing helped identify usability, configuration, notification, and device-specific issues before broader adoption.
What This Work Reinforced
Lessons that continue to shape how I lead.
Security and usability are not opposing goals
Security becomes stronger when people understand what they are being asked to do. Confusing experiences create workarounds, mistakes, and support burden.
Context matters at the moment of decision
An approval action is only meaningful when users can connect it to an expected sign-in attempt. The right contextual information can improve both confidence and security.
Enterprise flexibility should not become user complexity
Administrators need powerful configuration options, but users should receive a clear experience appropriate to their situation.
Mobile reliability is part of the product experience
Notification delivery, permissions, battery behavior, and device fragmentation may appear to be technical details. To the customer, they determine whether the product works.
Validation must reflect real operating conditions
Security-critical products need testing across actual devices, configurations, policies, and customer environments. Controlled testing alone does not reveal the complete experience.
Product Leadership Takeaway
Improving a critical point in the security journey, not just the screens.
This work demonstrates how I approach products where trust, usability, platform behavior, and enterprise requirements are tightly connected.
The objective was not simply to create better-looking mobile screens. It was to improve a critical point in the security journey, give enterprises greater control, help users make more informed decisions, and establish an experience that could continue to evolve as authentication requirements changed.
That required understanding the complete product system, making trade-offs visible, and keeping security, design, engineering, and customer needs aligned around a clear product direction.
Evidence
- ✓ Led the product evolution of native iOS and Android authenticator applications
- ✓ Delivered push authentication, one-time passwords, number challenge, device registration, and policy-driven journeys
- ✓ Introduced number challenge as a stronger, more deliberate verification method
- ✓ Simplified device registration across QR-code and link-based activation flows
- ✓ Enabled policy-driven authentication so enterprises control methods without adding user complexity
- ✓ Aligned native iOS and Android experiences around consistent product principles
- ✓ Coordinated enterprise beta validation across devices, configurations, and notification settings
- ✓ Kept mobile engineering, design, QA, security architecture, and SDK teams aligned around shared outcomes