Enterprise Identity Has a UX Problem

Hybrid work changed where employees work, how applications are accessed, and how quickly an attacker can exploit a stolen credential. It also forced security teams to confront an uncomfortable reality: identity has become the primary control plane for access.But for product managers and technology leaders, identity security is not only about protocols, policies, or compliance checkboxes. It is a product experience problem.Every authentication prompt, VPN reconnect, access request, posture-check failure, and “403 Forbidden” page sits directly in an employee’s daily workflow. When those experiences are poorly designed, teams lose time, developers work around controls, IT queues grow, and shadow IT becomes the path of least resistance.The goal is not to remove security controls. It is to make high-assurance access feel nearly invisible for legitimate users—while making unauthorized access far harder for attackers.The false trade-off between security and usabilitySecurity teams have traditionally treated usability and protection as a zero-sum trade-off.More security meant more passwords, more authentication prompts, more VPN friction, and more approval workflows. Better user experience often meant longer sessions, broader access, and fewer checks. That model no longer works.A modern identity platform should not force organizations to choose between strong controls and productive employees. Instead, it should continuously use contextual signals: such as device posture, authentication strength, user behavior, resource sensitivity, and request context; to apply the right level of control at the right time.The product-management challenge is to move beyond the old security-versus-usability curve.Rather than asking, “How much friction are users willing to tolerate for more security?” product leaders should ask:How can we deliver stronger assurance with fewer disruptive moments in the user journey?That shift changes how identity products are designed, measured, and prioritized.Identity has multiple customersOne reason enterprise identity products create frustration is that they are often designed primarily for the security buyer. The CISO, IAM architect, and compliance leader may approve the platform, but developers, business users, contractors, and IT operators experience it every day.A strong identity product must account for each of those groups.PersonaPrimary JobCommon FrictionWhat success looks likeEmployee or developerAccess the tools and environments required to do workRepeated MFA prompts, VPN failures, delayed permissions, expired sessionsFast, predictable access with minimal interruptionSecurity leaderReduce credential risk, contain blast radius, and enforce policyFragmented tools, unmanaged access paths, inconsistent controlsStrong visibility, rapid revocation, reduced standing privilegeIT or identity administratorProvision, troubleshoot, and govern access at scaleManual tickets, unclear ownership, repetitive remediationAutomation, clear workflows, and fewer support requestsCompliance or GRC leaderProve that access controls operate effectively Scattered logs, incomplete evidence, slow audit preparationCentralized evidence and reliable access historyThe lesson for product managers is simple: identity security cannot succeed if it optimizes only for the person buying the product.The end user is not an obstacle to security. Their behavior is one of the most important inputs into whether a control will work in practice.If access is too difficult, users find alternatives. They share credentials, delay critical work, use unauthorized SaaS tools, maintain broad permissions “just in case,” or ask administrators to weaken controls. Those workarounds create more risk than the original policy was meant to prevent.Design for high assurance and low interruptionThe best identity experiences do not eliminate controls. They replace repetitive, low-signal interruptions with stronger and more contextual signals.Replace repeated prompts with phishing-resistant authenticationTraditional passwords and one-time passcodes create friction without necessarily providing strong protection against modern phishing campaigns. Attackers can steal passwords, relay authentication sessions through adversary-in-the-middle infrastructure, or overwhelm users with repeated push notifications until one is approved.Passkeys and FIDO-based authentication offer a better product pattern. They use public-key cryptography and are designed to resist phishing by binding authentication to the legitimate application or domain. For users, the experience can be as simple as approving a sign-in with a device gesture or biometric verification.[1][2]The product lesson is not merely “add passkeys.”A good rollout must account for enrollment, device replacement, recovery flows, shared devices, fallback methods, and enterprise-managed endpoints. If recovery is confusing or inconsistent, users will fall back to weaker paths and administrators will inherit a new support burden.The goal is high assurance without turning authentication into a recurring interruption.Replace standing privilege with fast, scoped accessMany organizations still rely on permanent role assignments for access to production systems, cloud environments, databases, and sensitive internal tools. This creates a difficult choice:Grant broad, persistent access and accept a larger blast radius.Require manual approval for each request and slow down employees.A product-led approach removes that false choice through just-in-time access.Imagine an engineer responding to a production incident. They need limited database access for 60 minutes to validate a mitigation. Instead of filing a ticket and waiting for an administrator, the engineer requests access from the tool where the work is already happening—such as a CLI, incident platform, or collaboration workflow.The request includes relevant context:The resource being requestedThe requested durationThe active incident or change ticketThe engineer’s role and device postureRequired approval conditionsThe audit trail for the request and decisionIf policy conditions are met, access can be granted automatically. If human approval is needed, the appropriate owner can approve a narrowly scoped request. When the time window expires, the privilege is revoked automatically.This improves both security and productivity. The employee gets access when it is needed, and the organization avoids persistent permissions that can be abused long after the original task is complete.For PMs, the key metric is not just the number of access requests. It is **access-resolution time**: how long it takes a legitimate user to obtain the minimum necessary privilege to complete a legitimate task.Replace network access with application-level accessLegacy remote-access models often provide users with broad network connectivity once they connect through a VPN. This approach can be slow, operationally difficult, and risky. A compromised endpoint connected to an internal network may be able to discover or reach far more resources than the user actually needs.Zero Trust Network Access, or ZTNA, changes the model by connecting users to specific authorized applications rather than placing their devices broadly onto an internal network.For the employee, the desired experience is straightforward:Open the approved application and work.For the security team, the benefit is more granular control. Access decisions can account for identity, device posture, application sensitivity, location, risk signals, and policy. The user receives access to the approved application, not unrestricted visibility into internal network ranges.Microsegmentation extends this principle inside the environment. While ZTNA often governs user-to-application access, microsegmentation helps reduce unnecessary workload-to-workload communication. Together, these controls can reduce reachable attack paths and limit the impact of a compromised identity or workload.The product mistake is treating these technologies as interchangeable buzzwords. They solve related but distinct problems:ZTNA controls which applications a user can reach.Privileged access workflows control what sensitive actions a user can perform.Microsegmentation limits how workloads communicate after access is established.Identity governance helps determine whether the user should have access at all.A well-designed platform makes those controls feel connected to customers, even when the underlying enforcement points are different.Denials are product momentsOne of the most overlooked identity experiences is the access denial.Too many enterprise systems respond to a failed policy check with messages such as:“Access denied.”“Unauthorized.”“403 Forbidden.”“Contact your administrator.”These messages may be technically accurate, but they are product failures.A user who cannot access a system needs to understand what happened, what they can do next, and how to resolve the issue without opening a generic IT ticket.A modern identity experience should provide useful, policy-safe guidance:Your device needs an operating-system update before accessing this resource.Disk encryption is required for this application.Your temporary access expired 15 minutes ago.Your manager or incident commander can approve a 60-minute extension.This application requires phishing-resistant authentication.Your contractor access ends on a specified date and can be renewed by the sponsor.The interface does not need to expose sensitive policy details or help an attacker enumerate controls. But it should provide enough clarity for legitimate users to recover quickly.This is where product thinking matters. A denial is not the end of a workflow. It is a branch in the workflow.The best identity products convert an access failure into a self-service remediation path.Security onboarding should not require heroicsEnterprise security products often fail before users even begin using them.A customer may buy a strong platform, then spend weeks configuring agents, troubleshooting endpoint compatibility, mapping application dependencies, cleaning identity data, and resolving unclear policy failures. The result is slow time-to-value, expensive professional-services engagement, and frustrated administrators.Product managers should treat onboarding as a core security capability.A strong first-time user experience should help organizations:Connect their identity provider and directory sources.Validate user and group synchronization.Identify missing device-management or posture signals.Discover application dependencies before enforcing policies.Test policies safely before applying them broadly.Guide users through endpoint enrollment and recovery.Surface deployment blockers with actionable remediation.For example, instead of showing an administrator a vague message that a device is “non-compliant,” the product should identify the missing requirement, explain its impact, show the affected population, and provide an appropriate remediation path.The product outcome is not simply successful setup. It is faster, safer adoption at scale.A practical identity PM scorecardIdentity product teams should measure more than successful logins or policy coverage. They should track whether the product improves employee outcomes, reduces operational burden, and meaningfully lowers exposure.Product and user outcomes Security and governance outcomes Time to onboard a user, device, or applicationPercentage of privileged access that is time-boundAuthentication success and abandonment rateTime to revoke access after a role change or terminationAccess-resolution time for legitimate requestsCoverage of phishing-resistant authenticationPercentage of requests completed through self-serviceReachable attack-path reduction for sensitive systemsIT support ticket volume per employeeNon-human identity and credential inventory coverageTime to remediate a failed posture check Audit-evidence retrieval timeTime-to-value for a new customer deploymentPolicy exceptions, expiration, and review completion rateThese metrics should be used together.For example, reducing MFA prompts may improve user satisfaction, but it could be a bad outcome if the reduction comes from extending sessions indefinitely or weakening step-up authentication. Similarly, increasing self-service access may be beneficial only if requests remain scoped, time-bound, auditable, and governed by appropriate policy.Good product metrics capture both sides of the system: the user’s ability to get work done and the organization’s ability to manage risk.The real product goal: invisible securityThe future of identity security is not about building the highest possible barrier around every resource. It is about making security controls precise enough to become less visible to legitimate users and more effective against malicious activity.That requires product managers to think beyond feature checklists.The right questions are not only:Do we support MFA?Do we integrate with the identity provider?Do we provide audit logs?Do we have a ZTNA connector?The more meaningful questions are:Can a legitimate employee safely access what they need without unnecessary interruption?Can a security team remove access quickly when risk changes?Can an administrator understand and resolve a policy failure without opening a ticket?Can an auditor verify access decisions without weeks of manual evidence gathering?Can the platform enforce least privilege without slowing down critical work?When identity security is designed around those questions, it stops feeling like an organizational tax.It becomes an enabler of secure, distributed work: strong enough to reduce credential and access risk, simple enough to support real workflows, and intelligent enough to stay out of the way when everything is operating as it should.Sources[1] FIDO Passkeys: Passwordless Authentication https://fidoalliance.org/passkeys/[2] User Authentication Specifications https://fidoalliance.org/specifications-overview/