Passwordless IAM guide: how to solve the legacy systems problem without rebuilding them

1. Introduction: Why passwordless is still not the standard

Passwordless authentication has been discussed in the security industry for years. Today, it is no longer an experiment nor a niche technology reserved for early adopters. The underlying standards are mature, platform support is widespread, and passkeys are formally recognized as one of the most secure authentication mechanisms available.

Despite this, passwords remain deeply embedded in enterprise environments.

This contradiction is not the result of a lack of awareness. Large organizations understand the risks associated with passwords and the benefits of phishing-resistant authentication. Security teams, IAM architects, and compliance functions largely agree on the direction of change. The challenge lies elsewhere.

The real reason passwordless has not become the default in enterprises is architectural. Most organizations operate complex, heterogeneous environments built up over decades. Authentication mechanisms are tightly coupled to applications that were never designed with modern standards in mind. Replacing or rewriting these systems is often unrealistic due to cost, operational risk, and regulatory constraints.

As a result, passwordless authentication exists in theory, but not in practice, not at scale, and not consistently across the organization.

This article approaches passwordless IAM not as a single feature or product, but as an architectural challenge. It examines why traditional approaches fail, what actually blocks adoption, and how changes at the access architecture level make it possible to enforce passwordless authentication across both modern and legacy systems without rebuilding them.

For readers who want to see how these architectural challenges are addressed in a concrete enterprise IAM model, the Passwordless IAM use case outlines an approach to extending phishing-resistant authentication, based on FIDO2/WebAuthn passkeys, across both modern and legacy systems. It describes how passwordless and strong MFA can be enforced without modifying application code, how access can be federated across on-prem and cloud environments, and how regulatory requirements such as DORA, NIS2, and SCA can be met while preserving existing IAM infrastructure: https://secfense.com/solutions/iam

2. The promise of passwordless authentication

2.1 What passwordless really is (and what it is not)

Passwordless authentication is often mistakenly perceived merely as an improvement to the user experience rather than a fundamental change to the security model. In many conversations it is reduced to convenience: faster login, fewer credentials to remember, or better UX on mobile devices. Although these benefits are real, they are secondary.

In its essence, passwordless replaces shared secrets with cryptographic proof of key possession, not user knowledge. Instead of verifying something the user knows and may inadvertently or deliberately reveal, the system verifies the ability to perform a cryptographic operation using a private key that never leaves the user’s device. This model is defined by open standards developed by the FIDO Alliance, which introduced passkeys, FIDO2, and WebAuthn as phishing-resistant alternatives to passwords. Such a change eliminates entire classes of attacks, including phishing, credential stuffing, and password reuse.

Equally important is what passwordless is not. It is not limited to mobile devices. It is not dependent on a single vendor ecosystem. And it is not merely an overlay on existing password-based login processes. True passwordless authentication eliminates passwords and changes how trust is built between the user, the device, and the service.

2.2 Why passkeys became the reference standard

Passkeys have become the most widely accepted implementation of passwordless authentication because they combine strong security properties with standardization and broad platform support. Based on public key cryptography, they ensure that authentication credentials cannot be intercepted, reused, or reconstructed by an attacker.

Each authentication event is cryptographically bound to a specific service and the user’s device. This design makes passkeys inherently resistant to phishing and man-in-the-middle attacks. There are no shared secrets that can be captured and replayed in a different context.

Equally important, passkeys are not a proprietary mechanism tied to a single vendor ecosystem. They are standardized, interoperable, and natively supported by major operating systems and browsers. From the perspective of security and compliance, they represent a rare alignment of usability, cryptographic strength, and industry-wide standardization.

For readers who want a deeper explanation of how passkeys work in practice, including their cryptographic foundations, device binding, and differences from traditional credentials, a concise overview is available in the article “Passkeys for Workforce Identity – A Simple Guide”.

2.3 Why passwords still exist despite better alternatives

If passkeys are more secure and more convenient, maintaining passwords may seem irrational. In reality, it is the result of historical design decisions.

Most corporate applications were created on the assumption that authentication is handled locally, often directly in the application code. Passwords were simple to implement and widely supported. Over time these assumptions became permanently embedded in system architectures, processes, and operational practices.

As a result, authentication logic is tightly intertwined with application behavior. Replacing it is not a configuration change, but a structural intervention. Even when better alternatives exist, the cost and risk of change outweigh the perceived benefits.

That is why passwords still function. Not because organizations prefer them, but because their environments were never designed with anything better in mind.

This raises a common enterprise question: why does passwordless work so well in SaaS environments, yet consistently fail in large organizations?

3. Enterprise reality: why most organizations cannot “just deploy passkeys”

3.1 Legacy applications as a hidden constraint

In most large organizations, a significant portion of critical business systems falls into the category of legacy applications. Although they are still actively used and operationally critical, they typically do not support modern authentication standards.

Many of these systems cannot be extended with WebAuthn or modern MFA without modifying source code. In some cases, the original vendors no longer exist; in others, the applications are no longer actively developed. Even minor changes can require long validation and testing cycles due to regulatory or operational constraints.

From a security standpoint, legacy applications represent the most difficult risk to address. They store sensitive data, support key business processes, and remain tightly coupled to outdated authentication models. The Legacy App Protection use case describes how such systems can be secured with phishing-resistant authentication, without rewriting application code or disrupting existing infrastructure: https://secfense.com/solutions/legacy-applications

3.2 IAM complexity at enterprise scale

IAM environments in large organizations are rarely consistent and “clean.” Mergers, acquisitions, and years of organic growth lead to a mosaic of systems using different protocols, identity sources, and access models.

At the same time, there may be applications based on LDAP, custom cookie mechanisms, SAML, proprietary tokens, or authentication logic embedded in code. Each of these systems expects a different login method and reacts differently to changes.

In such an environment, imposing a single authentication standard becomes extremely difficult. Even with modern IdPs and MFA deployed, their reach often ends at the boundary of applications that can be integrated in a predictable way.

3.3 Why traditional modernization fails

A typical response to this problem is modernization: rewriting applications, updating platforms, or migrating to newer architectures. While such an approach can be effective in isolated cases, it rarely scales across the entire environment.

Modernization projects are expensive, time-consuming, and burdened with high risk. They require close cooperation among security teams, application owners, developers, and the business. Any mistake can lead to downtime or compliance issues.

As a result, modernization is postponed, narrowed, or abandoned altogether. Passwordless becomes a long-term goal rather than a real initiative.

The outcome is predictable: modern systems receive strong authentication, while legacy applications remain on passwords, creating inconsistent security coverage across the organization.

4. Passwordless IAM as a strategic problem, not a tactical one

4.1 Security expectations vs. technical feasibility

Most organizations know what good authentication should look like. They know industry recommendations, regulator expectations, and changing threat models. The gap appears between these expectations and what can realistically be implemented in the existing environment.

Security teams often face a difficult choice: enforce strong authentication where possible while accepting gaps elsewhere, or postpone deployment until a comprehensive solution is available. Neither option is satisfactory.

This tension makes passwordless IAM a strategic problem rather than purely a technical one. It affects the risk profile, audit readiness, and long-term security planning.

4.2 Passwordless as a governance and management challenge

From a governance perspective, inconsistent authentication is a serious problem. When different systems enforce different standards, it is difficult to define and demonstrate a uniform security policy.

Legacy applications protected only by passwords effectively set the lowest security level across the entire organization. Attackers do not target the most modern systems, but the weakest links.

Auditors and regulators also assess coverage, not intentions. Partial deployment of strong authentication does not eliminate risk if critical systems remain out of scope.

4.3 Why partial passwordless is not enough

Passwordless authentication delivers full value only when it is applied consistently. A hybrid environment in which some systems are passwordless while others still rely on passwords increases complexity instead of reducing it.

Operationally, this means a greater burden on security teams. Strategically, it undermines trust in the organization’s real level of protection.

That is why passwordless IAM cannot be treated as a tactical upgrade or an isolated project. It requires an architectural approach that covers the entire environment, including systems that were never designed with modern authentication in mind.

5. Two perspectives: what passwordless IAM means for different roles

Passwordless IAM is often presented as a single initiative, but in practice it affects different areas of responsibility in an organization. Although the underlying problem is the same, security leaders and IAM architects perceive it from different perspectives. Understanding both points of view is key to designing an approach that is simultaneously technically feasible, operationally safe, and defensible during an audit.

5.1 The perspective of the CISO and compliance teams

From the perspective of security leaders and compliance teams, passwordless IAM is primarily an issue of risk management and organizational governance. The key question is not how authentication works in individual systems, but whether the organization can demonstrate consistent and enforceable control mechanisms across the entire environment.

One of the main focus areas is phishing resistance. Password-based authentication, even when combined with traditional forms of MFA such as SMS or one-time codes, remains vulnerable to social engineering and credential theft. More and more regulations and security frameworks expect mechanisms that eliminate these risks at the root, not merely reduce them.

The second key problem is coverage. In many organizations, strong authentication is applied selectively: modern cloud applications are protected by advanced MFA, while legacy systems still rely on passwords. From a compliance perspective this creates a structural weakness. Auditors and regulators assess the overall risk profile, not individual improvements. One weak system can undermine the effectiveness of protections implemented elsewhere.

Auditability is equally important. Security leaders must be able to demonstrate not only the existence of strong authentication, but also its consistent enforcement and centralized monitoring. Dispersed login mechanisms make it difficult to provide unambiguous evidence of who, when, and under what conditions gained access to systems. The lack of such visibility increases both operational risk and regulatory exposure.

From the perspective of the chief information security officer, a passwordless approach to identity management represents a real opportunity to simplify oversight and control rules.

A uniform authentication model reduces ambiguity, strengthens policy enforcement, and makes compliance easier to demonstrate. The challenge remains achieving this consistency without destabilizing critical systems.

5.2 The perspective of IAM architects and enterprise architects

IAM architects look at passwordless through the lens of feasibility in complex, inherited environments. While the benefits of passkeys and phishing-resistant authentication are clear, in practice decisions are determined by architectural constraints.

In many organizations, modern IdPs and MFA solutions already exist, but their reach is limited. These tools operate at clearly defined integration points and assume that applications can delegate the authentication process externally. Legacy applications often do not meet this assumption. Their login logic is embedded directly in the application, which prevents the process from being intercepted by modern IAM mechanisms.

This problem intensifies as the environment grows through mergers and acquisitions. Each application brings its own assumptions about authentication, protocols, and dependencies. Enforcing a single standard stops being a configuration task and becomes an attempt to rebuild architecture.

This was exactly the case at BNP Paribas Bank Polska, whose IT landscape evolved through multiple mergers and the integration of heterogeneous systems over many years. You can read more about how the bank was nevertheless able to introduce passkeys and phishing-resistant authentication across this complex environment, without modifying existing applications, in the article “BNP Paribas Bank Polska Partners with Secfense on Modern Authentication”:

Architects must also consider operational stability. Any change in login flows carries a risk of system outages. Introducing new authentication methods at the application level requires testing, coordination, and rollback plans. In the case of critical systems, this risk often outweighs the potential benefits of modernization.

From this perspective, the passwordless IAM problem does not result from a lack of standards or tools, but from the tight coupling between authentication and application behavior. Solving it requires separating authentication enforcement from the applications themselves.

Key observation:
Although CISOs and IAM architects focus on different aspects of passwordless IAM, both roles encounter the same constraint. The existing architecture does not allow consistent enforcement of modern authentication across all systems.

6. What actually blocks passwordless adoption

6.1 It’s not passkeys

In discussions about passwordless, it is often assumed that passkeys themselves are the key challenge. In reality, the standards and cryptography behind passkeys are already mature: the specifications are stable, platform support is broad, and the security properties are well defined and understood.

From a technical standpoint, passkeys eliminate shared secrets, are phishing-resistant by design, and create a strong cryptographic binding between the user, the device, and the service.

The difficulty does not lie in generating or verifying passkeys, but in deploying them in environments that were never designed with this authentication model in mind.

6.2 It’s architecture

The primary blocker for passwordless IAM is architecture. In most organizations, authentication is not a central service but a distributed function, implemented differently across individual systems.

Applications often control their own login processes, session management, and authorization logic. This model was rational at a time when passwords were the universal standard, but today it has become a serious limitation.

Without a common enforcement point, each application must be modified individually to support passkeys. This turns passwordless adoption into a series of separate projects rather than a scalable initiative.

In practice, this means that the pace of change is dictated by the oldest and most problematic systems. The age and diversity of the application environment define the limits of what can be achieved.

6.3 Why existing IAM tools are not enough

Modern IAM platforms and IdPs are powerful, but they operate within specific boundaries. They authenticate users and issue tokens, but they do not always control how sessions are established and maintained within applications.

MFA solutions typically assume that applications can redirect users, verify assertions, or support a standard protocol. Legacy systems often meet none of these assumptions. As a result, they remain outside the reach of modern enforcement mechanisms.

This creates a structural gap. IAM tools can define policies, but they cannot enforce them everywhere. Passwordless becomes possible in theory, but incomplete in practice.

6.4 Consequence: passwordless as an exception, not a standard

When architecture limits enforcement, passwordless authentication is deployed selectively. It becomes an exception applied to modern systems, rather than a standard enforced across the entire organization.

Such selective adoption undermines the strategic value of passwordless IAM. Security improvements are real but fragmented. Governance becomes more complex, not simpler. The organization remains exposed through the systems that are hardest to change and easiest to attack.

To move beyond this state, passwordless IAM must stop being perceived as something implemented at the application level. It must be approached as an architectural capability, one that can be introduced without rewriting the systems it is meant to protect.

The real question enterprises face is not whether passkeys are secure, but how they can be enforced when applications cannot be changed.

7. The missing layer in enterprise IAM

Up to this point, the passwordless IAM problem has been described mainly through the lens of constraints. Legacy applications, distributed architecture, and authentication logic embedded in systems effectively prevent consistent enforcement of modern standards across the entire environment. The natural question, then, is not whether passwordless authentication makes sense, but how to deploy it without dismantling the existing infrastructure.

The answer does not lie in replacing the IAM vendor, rewriting applications, or introducing yet another login mechanism. It lies in adding the missing architectural layer.

7.1 The concept of an enforcement layer

In traditional enterprise architectures, authentication is either handled directly by applications or delegated to an IdP through integration. In both cases, security policy enforcement depends on the application’s ability to participate in the login process.

This model does not work in heterogeneous environments. If an application cannot be modified, authentication policies remain a statement of intent rather than a mechanism that is actually enforced.

An access control layer changes this paradigm. Instead of relying on applications, authentication is performed centrally, at the point where all user traffic converges before reaching systems. This layer operates independently of application logic, intercepting access requests before they reach the application.

From an architectural perspective, this means a separation of responsibilities. Applications retain their business logic, while authentication and access enforcement are handled centrally. This separation enables the introduction of new authentication standards without interfering with protected systems.

7.2 User Access Security Broker (UASB) as an architectural pattern

User Access Security Broker (UASB) is best understood not as a product category, but as an architectural pattern that addresses the needs described above.

UASB is not a new IdP. It does not replace existing IAM platforms, user directories, or identity sources. It is positioned between the user and the application, acting as an intermediary that controls how access is established.

At a high level, UASB intercepts login attempts, performs authentication using modern methods such as passkeys, and then enables access to the application in a form that the application already understands. From the application’s perspective, nothing changes. From the organization’s perspective, authentication policies become central and are actually enforced across the entire environment.

This distinction is critical. By avoiding changes to application code, protocols, or session mechanisms, the UASB pattern removes the main barriers to passwordless adoption.

7.3 Why this layer was unavailable before

For years, organizations tried to solve authentication problems either at the application level or through central IdPs. Both approaches, however, assume a level of control over applications that often does not exist in practice.

The enforcement layer was missing because it required a combination of factors that have only recently become viable: mature passkey standards, reliable device authentication, and the ability to integrate at the network or access layer without disrupting production traffic.

As a result, organizations were forced to choose between partial modernization and accepting the risk posed by legacy systems. The emergence of UASB changes this relationship. It allows authentication to evolve independently of the application lifecycle.

7.4 How UASB changes the way passwordless IAM is approached

Introducing a central access control layer causes passwordless IAM to stop being application-oriented and become an architectural element. Instead of asking whether a given system supports passkeys, organizations can ask whether access to that system can be mediated centrally.

This shift in perspective has far-reaching consequences. Passwordless authentication becomes possible even for systems previously considered “untouchable.” Policies can be defined once and enforced everywhere. Coverage gaps disappear not because applications were modernized, but because they were protected externally.

Most importantly, this approach turns passwordless IAM from a long-term aspiration into a real deployment program. It allows security goals to be reconciled with operational realities and enables modern authentication to be rolled out at the organization’s own pace, without rebuilding infrastructure.

8. Passwordless IAM without rebuilding the environment

Introducing a central enforcement layer fundamentally changes how passwordless IAM can be deployed in enterprise environments. Instead of requiring every application to support modern authentication standards, the User Access Security Broker pattern makes it possible to introduce passkeys at the access level, without modifying application code or authentication logic.

This section explains what this looks like in practice.

8.1 Intercepting access without interfering with applications

In a typical enterprise environment, user access to applications already passes through a limited number of control points. These may include load balancers, reverse proxies, access gateways, or other layers that mediate incoming traffic.

UASB is deployed precisely at this point where it can observe and control authentication flows before they reach the application. From a network and systems perspective, this is critical because it ensures that all access attempts pass through a single enforcement point, regardless of how authentication is implemented inside the application.

Because UASB operates outside the application, it does not require changes to application code, authentication modules, or session management mechanisms. The application remains unaware that modern authentication has been introduced “in front of it.”

8.2 External authentication based on passkeys

When a user attempts to access an application, UASB intercepts the request and initiates an authentication process using passkeys or other phishing-resistant methods. This entire process is carried out outside the application.

The user confirms their identity locally, on the device, using biometrics or a PIN. UASB verifies the cryptographic proof and checks whether it meets the organization’s security policy requirements.

From the user’s perspective, the experience is consistent regardless of the application. From the organization’s perspective, authentication policies are enforced centrally and uniformly.

Crucially, the private cryptographic material never leaves the user’s device. All security properties of passkeys are therefore preserved, even in environments that were not originally designed for this authentication model.

8.3 Passing the session in a format accepted by the application

After successful authentication, UASB passes the authentication context to the application, allowing it to establish a session in an already supported form (session cookie, trusted HTTP header, etc.).

No new protocols are introduced at the application boundary. There is no need to change how sessions are validated or maintained. From the application’s perspective, the user has been authenticated in the same way as before.

This step is what makes the UASB pattern applicable in legacy environments. It translates modern authentication into formats compatible with the application’s historical assumptions.

8.4 Why the IAM architecture remains untouched

One of the key advantages of this approach is that it does not interfere with the existing IAM architecture. Identity sources, user directories, and IdPs continue to operate as before. Identities, roles, and entitlements are still managed in the systems already in place.

UASB enforces authentication policies without redefining identity ownership or access models. It complements existing IAM tools rather than competing with them.

As a result, organizations can roll out passkeys gradually. Passwords can be phased out step by step, application by application or user group by user group, without creating parallel identity silos or duplicating configuration.

8.5 From modernization projects to an architectural capability

Traditional passwordless initiatives often resemble modernization projects: large, time-bound efforts focused on specific systems. Their pace depends on development cycles, testing windows, and business approvals.

The UASB pattern turns passwordless IAM into an architectural capability. Once the enforcement layer is in place, new authentication methods can be introduced centrally and applied consistently.

This shift reduces risk and increases predictability. Organizations can move from pilots to broad adoption in a controlled way, without tying security improvements to the application lifecycle.

Passwordless IAM becomes a matter of policy and architecture, not code and system rebuilds.

9. Operational and security implications

Introducing passwordless IAM through a central access control layer is not purely an architectural decision. It has a direct, measurable impact on how security is managed, how audits are conducted, and how day-to-day operations function. Separating authentication from applications and centralizing enforcement changes the approach to risk, visibility, and cost across the entire environment.

9.1 Full coverage instead of selective protection

One of the most visible effects of the UASB-based approach is the shift away from selective protection. In traditional deployments, strong authentication is often limited to systems that support modern integrations. Legacy applications are excluded not by choice, but due to technical constraints.

With a central access control layer, authentication policy is applied at the access level rather than the application level. This makes it possible to apply the same standards to all systems, regardless of their age or technical limitations.

From a security perspective, this is critical. Attackers rarely choose the most modern and best-protected systems. They focus on the weakest entry points. Eliminating password-only access across the entire environment reduces the attack surface and removes the asymmetry that adversaries exploit.

Full coverage also simplifies security decision-making. Instead of managing exceptions and compensating controls, organizations can define a single baseline level and enforce it consistently.

9.2 Auditability and evidence

Auditability is one of the most critical requirements in regulated organizations and, at the same time, one of the hardest to achieve in complex IAM environments. When authentication mechanisms are distributed across applications, access logs become fragmented, inconsistent, and difficult to correlate. Reconstructing who accessed which system, when, and under what conditions often requires manual effort and incomplete data.

Centralizing authentication enforcement fundamentally changes this situation. When all access flows pass through a single control layer, authentication events are recorded in a consistent and uniform way. This creates a reliable audit trail that can be correlated with identity data and application activity across the entire environment.

For auditors and regulators, this consistency is often more important than the specific authentication technology used. The ability to provide clear, unambiguous answers to questions such as who authenticated, how, to which system, and under which policy becomes significantly easier when enforcement is centralized rather than distributed.

These expectations are reflected in guidance published by the NIST. Documents such as NIST SP 800-63 emphasize phishing resistance, cryptographic authentication, and verifiable assurance levels as foundational requirements for modern identity and access management, particularly in regulated and high-risk environments.
https://pages.nist.gov/800-63-3/

From an operational perspective, centralized authentication logging also improves incident response. Security teams can analyze authentication-related events holistically, without aggregating logs from dozens of systems with different formats and retention policies, reducing response time and increasing confidence in forensic conclusions.

9.3 Reduction of operational costs

Passwords generate significant operational costs. Helpdesk tickets related to password resets, account lockouts, and access recovery consume time and resources. In large organizations, these costs accumulate quickly and are often treated as an unavoidable part of operations.

Passwordless authentication significantly reduces this burden by eliminating the most common causes of access issues. When authentication is based on device-bound credentials rather than shared secrets, the number of resets and lockouts drops sharply.

The architectural approach also reduces hidden costs of security projects. Avoiding application-level changes eliminates the need for development work, long testing cycles, and coordinated deployments. Security improvements can be introduced without disrupting business operations and without involving development teams.

Over time, this leads to greater cost predictability. Authentication becomes a centrally managed service rather than a collection of application-specific implementations, reducing complexity and maintenance costs.

9.4 Simplified policy management and enforcement

Centralized access control enables simpler and more consistent policy management. Authentication rules can be defined once and applied across the entire environment, rather than translated into application-specific configurations.

This consistency reduces the risk of configuration drift, where systems gradually deviate from accepted security standards. It also makes change easier. Updating authentication requirements can be done centrally, without modifying individual applications.

From a governance perspective, this brings security policies closer to operational reality. Defined controls are not merely documented, they are enforced by design.

10. How this architectural model works in practice

The approach described earlier, based on a central access control layer, is not a theoretical construct. It has been deployed in production environments where traditional IAM models were unable to provide consistent, phishing-resistant authentication in infrastructures dominated by legacy systems. Understanding how this model operates in practice helps explain why it succeeds where earlier approaches failed.

Examples of such real-world deployments, across banks, insurers, and public-sector institutions operating under regulatory and legacy constraints, are documented in Secfense customer case studies: https://secfense.com/clients-stories

10.1 Deploying the UASB pattern without disrupting existing IAM

In real-world deployments, the User Access Security Broker is introduced as an additional architectural layer, not as a replacement for existing systems. Existing IdPs, user directories, and access management processes remain unchanged. UASB is placed in the access layer, most often alongside or integrated with reverse proxies or load balancers.

This deployment model has already been applied in large, regulated organizations operating complex, heterogeneous IAM environments shaped by years of mergers and system integrations. A representative example is BNP Paribas Bank Polska, where passkey-based, phishing-resistant authentication was introduced across internal and customer-facing systems without modifying existing applications or disrupting daily operations. A detailed description of this journey, including architectural decisions, constraints related to legacy systems, and the phased rollout approach, is available in the article “BNP Paribas Bank Polska Partners with Secfense on Modern Authentication”.

This placement makes it possible to apply authentication policies without reconfiguring applications or redefining identity ownership. User identities, roles, and entitlements continue to be managed in the existing IAM systems. The central access control layer focuses solely on how access is authenticated, not on who the user is or what they are authorized to access.

This separation of responsibilities is critical. It reduces organizational resistance, lowers risk, and enables passwordless IAM to be deployed incrementally rather than through disruptive transformation projects.

10.2 Reference implementation: Secfense

Secfense implements the UASB pattern as a practical, production-ready architecture designed for environments where legacy applications cannot be modified.

In this model, Secfense operates at the network and access level, intercepting authentication flows before they reach applications. Users are authenticated using phishing-resistant methods such as passkeys, while applications receive sessions in formats they already support. From the application’s perspective, nothing changes. From the security teams’ perspective, authentication policies become central and enforceable.

Importantly, this approach does not require user migration, identity duplication, or the creation of parallel IAM stacks. Integration with existing directories, IdPs, and login systems allows the access control layer to complement the current IAM environment rather than compete with it.

10.3 Deployment characteristics that matter in practice

Successful passwordless IAM deployments based on a central access control layer share several common characteristics:

No application changes
Authentication is enforced externally, without modifying code, protocols, or login logic.

No downtime
The central access control layer can be introduced without disrupting production systems, which is critical in regulated and high-availability environments.

Gradual rollout
Organizations can start with selected applications, user groups, or high-risk scenarios and expand the scope over time, without redesigning the solution.

Central policy control
Authentication rules are defined once and enforced consistently across all protected systems.

These characteristics are what make the central access control approach viable at enterprise scale. It aligns security improvements with real operational constraints instead of working against them.

10.4 From architectural concept to real-world operation

What differentiates practical deployments from earlier passwordless initiatives is not the authentication technology itself, but the deployment model. Introducing an enforcement layer that operates independently of applications finally reconciles modern authentication standards with the realities of legacy environments.

In this view, passwordless IAM stops being an aspiration and becomes an operational capability. Security teams gain the ability to consistently enforce phishing-resistant authentication. Architects receive a solution aligned with existing environments. Executives gain predictability and audit readiness without the risk of large-scale system changes.

This is the point at which passwordless IAM moves from theory to practice, not by modernizing applications, but by enabling it at the architectural level.

11. The most common pitfalls in passwordless IAM programs

Organizations that attempt to deploy passwordless authentication very often encounter the same problems, regardless of industry, scale, or level of regulation. Most often, these issues result from treating passwordless IAM as a tactical modernization rather than an architectural change.

Understanding these mistakes helps explain why many initiatives stall halfway and how they can be avoided.

11.1 Treating passwordless as a UX project

One of the most common misunderstandings is viewing passwordless primarily as a user experience improvement. While faster login and greater convenience are real benefits, focusing exclusively on UX leads to shallow deployments.

In this approach, passwordless is:

• deployed selectively,

• limited to chosen, modern applications,

• not tied to an organization-wide security policy.
  
  
  

The result is predictable: passwords disappear from some login screens but remain the foundation of the environment. The organization improves convenience without materially improving its risk profile.

11.2 Assuming that upgrading IdP or MFA will solve the problem

Another frequent pitfall is the belief that replacing or upgrading an IdP or deploying a new MFA will automatically enable passwordless IAM across the entire organization.

In practice, IdPs and MFA systems enforce policies only where applications can delegate authentication. Legacy systems often remain outside this scope. The result is a two-tier model:

• modern applications with strong authentication,

• legacy applications still protected by passwords.
  
  
  

This state creates a false sense of progress. The IAM stack looks modern in presentations, but enforcement remains incomplete.

11.3 Accepting partial coverage as “good enough”

Partial deployment is often justified pragmatically: “it’s better to secure most systems than none.” While this may sound reasonable in the short term, in the long run it creates strategic risk.

Attackers do not respect architectural boundaries. They will always choose the weakest entry point- often a legacy system excluded from modern mechanisms. From a governance and audit perspective, partial coverage also weakens the organization’s ability to demonstrate consistent policy enforcement.

Passwordless IAM delivers full value only when applied consistently. Every exception preserves the weaknesses it was meant to eliminate.

11.4 Treating legacy systems as permanent exceptions

Legacy applications are very often treated as permanent exceptions, protected by compensating controls instead of being included in the main security model. This approach entrenches architectural fragmentation.

Over time, exceptions accumulate. Security policies become increasingly complex, documentation stops reflecting reality, and operational risk grows. Legacy systems cease to be marginal, they begin to define the constraints of the entire IAM strategy.

An approach based on a central access control layer challenges this assumption by securing legacy systems externally, without forcing their modernization.

11.5 Underestimating the role of auditability

Some passwordless initiatives focus exclusively on authentication strength, overlooking auditability and evidence. Even very strong authentication loses much of its value if it cannot be logged consistently, correlated, and demonstrated during an audit.

In regulated organizations, it is necessary to prove:

• that authentication policies are enforced,

• that they cover all relevant systems,

• that access events can be unambiguously reconstructed.
  
  
  

Distributed deployments make meeting these requirements difficult, even if the authentication methods themselves are modern.

11.6 Confusing technology availability with architectural readiness

Finally, one of the most fundamental mistakes is equating technology availability with environmental readiness. The fact that passkeys exist, standards are stable, and platforms support them does not mean the organization’s architecture is ready for deployment.

Without a central access control point, passwordless remains dependent on application capabilities. It is this dependency that causes initiatives that are technically feasible to turn into long-running, high-risk modernization projects.

The common conclusion from unsuccessful or stalled programs is always the same: passwordless IAM cannot function as a layer added onto a fragmented architecture. It requires a deliberate change in where authentication is enforced.

12. Summary and readiness checklist

12.1 Passwordless IAM as an architectural change

In short: Passwordless IAM adoption fails in enterprises not because of cryptography, standards, or user readiness, but because authentication enforcement is embedded in applications. Until enforcement is moved to a shared access layer, passwordless will remain partial and inconsistent.

Passwordless authentication is no longer a question of standards maturity or vendor readiness. Passkeys are widely supported, phishing-resistant, and increasingly recommended by regulations and security frameworks. Technology was never the obstacle.

The real barrier was architecture.

Enterprise environments were built around applications that implemented their own authentication logic. Over time, this led to fragmented access control, coverage gaps, and a growing divide between security expectations and real-world feasibility.

Introducing a central access control layer fundamentally changes this situation. By separating authentication from applications and centralizing it at the access level, organizations can finally deploy modern authentication in a consistent way, without rewriting systems, interrupting operations, or rebuilding IAM from scratch.

This is not a cryptographic breakthrough.
It is an architectural breakthrough.

12.2 What changes when passwordless IAM can be enforced

When authentication enforcement is moved outside applications:

• coverage becomes complete - legacy systems are no longer automatically excluded,

• governance is simplified - policies are defined once and applied everywhere,

• auditability improves - authentication events are consistent and demonstrable,

• operational risk decreases - security is no longer tied to the application lifecycle.

The organization’s security posture stops being defined by its weakest system and starts being defined by policies enforced at the access level.

12.3 Passwordless IAM readiness checklist

The checklist below can serve as an initial self-assessment of an organization’s readiness to deploy passwordless IAM at enterprise scale.

Architecture and enforcement

• Do all user access paths pass through a controlled access layer?

• Can authentication be enforced independently of application logic?

• Is it possible to introduce new authentication methods without application changes?
  
  
  

Coverage and consistency

• Can the same authentication policies cover both modern and legacy systems?

• Are there critical applications accessible using passwords only?

• Is authentication consistent across all environments (on-prem, cloud, hybrid)?
  
  
  

Security and risk

• Does the organization use phishing-resistant authentication in high-risk scenarios?

• Are shared secrets still the primary authentication mechanism?

• Can attackers bypass strong authentication by targeting legacy systems?
  
  
  

Audit and compliance

• Are authentication events logged centrally and consistently?

• Is it possible to reconstruct who accessed what, when, and under what conditions?

• Can authentication enforcement be demonstrated during an audit, not just described in documentation?
  
  
  

Operations and scalability

• Can passwordless be rolled out gradually?

• Can policies be changed centrally, without coordinating application changes?

• Is the operational cost of passwords (resets, lockouts, access recovery) visible and measured?
  
  
  

Summary

Passwordless IAM stops being a vision of the future once it is no longer treated as a problem of individual applications and instead is addressed at the access architecture level. Organizations that attempt to deploy passwordless solely through system modernization inevitably encounter the constraints imposed by their oldest applications and legacy environments.

An approach based on an intermediary, central access control layer makes it possible to separate authentication from applications and introduce modern, phishing-resistant login methods without code changes, without downtime, and without rebuilding existing IAM. As a result, security can evolve independently of the age and limitations of the systems being protected.

Secfense is a provider of technology that implements this model in practice. The Secfense platform implements the User Access Security Broker (UASB) pattern, enabling the deployment of passkeys and passwordless IAM in enterprise environments dominated by legacy systems, in a controlled, auditable, and regulation-compliant manner.

If your organization is evaluating how to realistically move away from passwords without rebuilding applications, redesigning the entire IAM stack, or introducing operational risk, the next step is a discussion about architecture and a viable deployment model.

To discuss specific scenarios, validate feasibility, or talk about how Secfense can help in your environment, please contact the Secfense team:
👉 https://secfense.com/contact