Achieving Passwordless Is Trickier Than You Think – 12 Key Considerations

Introduction

The ideal of achieving a true passwordless operating environment is a universally accepted one. The benefits to both a better user experience and to improved security are clear. It comes as no surprise then that passwordless is taking centre stage in industry discussions and with vendor product focus alike.

However, the path to achieving complete password replacement is not trivial, and there’s no simple middle ground. It’s not possible to have a “mostly passwordless” outcome, to implement just a little bit here and a little bit there. True benefits are realised only when you’re all in, and passwords are eliminated in totality.

This means that you need to be well equipped to tackle passwordless with both the right approach, the right tools, and well supported projects. To help you come to grips with all the aspects you need to consider, I outline 12 key factors that are critical to a successful passwordless implementation.

1- True Passwordless or Password Masking?

Many “middle-ground” password elimination strategies simply swap in a convenience biometric, that unlocks a hidden password. This password is then used in the background and is not actually removed from play. These masked passwords can still be weaponised by fraudsters, as invariably there will be fallback processes that still rely on them. Further, from a convenience perspective, some biometrics have password/PIN equivalents by design. For example in iOS and Windows Hello, a failed convenience biometric falls back to a PIN / knowledge factor at the OS level – which can still unlock the secure element with an equivalent level of assurance.

In these cases, the inherence factor is readily bypassed, and so a true passwordless solution is still not achieved. This is an important concept to understand. Convenience biometrics have limited efficacy in a passwordless world.

2 – Support for numerous devices, platforms and operating systems

Most environments are heterogenous, and the mixed use of Windows, Mac, Unix, iOS and Android, are all very common. For this reason, passwordless capability must span all of these environments, as fallback to a password based solution in any one OS results in a generalised fallback for the entire enterprise.

If you have great passwordless support for Windows, but rely on passwords for Mac for example, then any resources available through this lowest common denominator is still at risk.

Passwordless means that you have to take stock of every OS in your organisation, and implement a replacement solution. This likely results in the need for multiple approaches, and to use multiple technologies. You should expect this, and architect for the necessary interplay that occurs between these technologies.

3 – Support for Offline

There continues to be many use cases where offline access is still very important (logging into a Windows machine on a flight is a common example). If you rely on push notifications, SMS, or a biometric from an external channel, what do you do when the network is unavailable?

In such cases, integrated OTP in offline generation mode is still a strong and viable technology, even though it is arguable that such methods are “outdated” and difficult to use. So the question is – how do you ensure your architecture is modernised, whilst still supporting these critical backup modes? And can your IAM systems recognise when you are offline, and provide the right credential capability automatically at the right time? These factors are important when it comes to seamless usability.

4 – Employees, Contractors, 3rd parties and BYOD

Organisations are rarely made up of internal staff alone. A workforce often includes contractors and third parties that are outside the firewall, and/or have a mix of devices that aren’t even to corporate standard.

Again, passwordless necessitates the elimination of passwords right across the enterprise, and so the same technologies must be relevant for third parties also. You will need to take stock of your external third party access points, understand your provisioning and credentials management processes, and cater for this often overlooked area.

Don’t allow a single lowest common denominator undermine all your good work. You have to be passwordless everywhere!

5 – Shared devices and kiosks

Where shared devices are utilised, a solid multi-user setup is critical. Shared devices also need to respond to push events that are user contextual.

Shared devices for staff are where FIDO based authenticators can work very well, for example U2F keys. Centralised biometrics are also useful, so that staff accessing devices for the first time are authenticating against a centralised system, rather than having to “enrol” against a new device every time.

6 – Integration to new authenticators

As authentication technologies evolve, the passwordless authentication processes used in lieu of knowledge factors must also evolve. New devices introduce new biometric readers, and these should be leveraged as quickly as they are pushed to market. Indeed, without passwords, new authenticators and devices are the very lifeblood of your passwordless solution.

And the reverse is also true, authenticators that become insecure must also be de-provisioned or disabled just as quickly. Because in a passwordless world, being able to fallback to a simple password is not an option, so what do you fallback to? Being able to manage any number of devices and credentials is an important underpinning of any passwordless solution. Options, secondary options, and fallback processes have never been more important.

7 – Integration into your existing applications

A quick Google search tells us that the “modern” computer password was invented 60 years ago, in 1960. This means that the use of passwords have had a lot of time to ingrain itself into just about every corner of computing and application design.

Going passwordless explicitly implies that your applications need to change, which on the face of it, is not great news. It is not uncommon for organisations to be maintaining literally hundreds or possibly thousands of legacy applications. Indeed this is a significant pointer to the way that applications should be built both now and in the future; to be divorced from driving the method of authentication in the first place. Security processes and policies should be linked to your application, and not baked in code.

The lesson here is that going passwordless means more than just implementing a password replacement technology. It means considering everything underneath in the application space too.

8 – New User Registration and device re-registration

When we use our devices to authenticate, how do we begin the process of authenticating to the device in the first place? Classically, this is through passwords to bootstrap the identity process, or through email links – which in itself, is secured with passwords.

Setting up a new device, or re-registering an account with an existing device, requires a rethink on the typical ways that devices are bootstrapped. And this is commonly a point of contention for organisations today, with call centres often utilised as the fallback of all fallbacks, which results in knowledge based Q&A being used to secure an account (what is your DOB? What was the last transaction on your savings account?). This is costly for the enterprise to run, and a favourite attack vector for fraudsters everywhere.

9 – Enhanced Authorisation Controls

With risk-based policy, the capacity to perform expanded and more meaningful authorisation is enhanced.

Older password based systems are often quite binary in nature, and simply being able to get into an application is all that is needed. In the age of passwordless and zero trust, we are dealing with more fine-grained checks on authenticity, and so the capacity to be able to utilise strong authorisation modelling is ripe. Why not use this paradigm shift to also up the ante in how you authorise events and transactions too.

10 – Risk and Trust

Passwordless relies on a new paradigm of risk and trust assessment, as it is founded on the concepts of a zero trust framework.

We have to assume all devices and intentions to be untrusted until proven otherwise, and this requires leverage of suitable risk and trust engines that continually examine the posture of an actor accessing a system.

By utilising strong risk analytics, additional supporting factors come into play rather than simple credential factors alone (e.g. I have a device and my thumb). This can include such things as specific device fingerprinting, location history, source network access details, transaction heat mapping and profiling etc. All of these things build a richer picture of digital intent. (e.g. I am using my work iPhone 8 Plus, on my office network, between the hours of 9AM and 5PM).

Certainly, as fallback authentication methods become fewer, noting that we can’t rely on a password anymore, additional knowledge and intel about what is being used, how it is being used, and when it is being used, becomes more important than ever before.

So the question is: Does your IAM solution support inbuilt risk and trust capability, and can it be used adequately within your digital stack? If this is still a bridge too far, you need to be aware that achieving passwordless is an unlikely outcome. You really need to bring this capability online and make it work.

11 – Rip And Replace Is Usually Not Feasible

As you look to implementing passwordless solutions, the approach of a total replatform might well be considered.

However, very few circumstances arise that allow for a rip and replace approach, and even then, you need to be sure that all facets of passwordless will be catered for in that replatforming, both now and in the future.

A better approach is to augment your architecture with technology that allows for vendor agnostic integration and orchestration, and in the areas needed.

12 – Reliance on a Single Vendor

When you look at the key underpinnings of zero-trust passwordless, there are quite a few concepts in play – and these areas are serviced by a myriad of vendors. Here’s a short-list of some of the technologies you’ll be executing against:

  • Application integration and frameworks
  • Device Management
  • Identity Management
  • Threat Detection
  • Risk Assessment
  • Authentication tools
  • Access Controls and Authorisation
  • Data centres, cloud, and multi-cloud

It is quite likely you’ll be working with various vendors to solve all these problems. Key then, is to be able to efficiently work with these numerous technologies, and architect your solution to avoid mixed vendor incompatibility and vendor lock in.

Conclusion

Implementing Passwordless is a major undertaking when you do it right, and it is hoped that this discussion has shed some light on the size and breadth of the problem space.

We’ve also seen that there is no single silver bullet or service that makes passwordless happen – you can’t buy a product off the shelf, unbox it, and achieve true passwordless across your enterprise. It takes careful assessment and uplift in many areas.

But there are technologies and strategies that are highly cognisant of, and suited to, the art of creating a Passwordless world. Transmit Security is a Zero Trust Passwordless enabler, not only through its capacity to supply key capabilities in all areas of passwordless design, but encourages a vendor agnostic integration methodology to enable you to more easily build your passwordless platform using the technologies you might already have.

Build your architecture according to abstracted security design. Utilise orchestration, credential equivalence and fallbacks, and integrated risk assessment to facilitate low friction authentication journeys and flows.

Passwordless can be more easily attained through the confluence of numerous IT Security and IAM concepts. These concepts are at the very core of the Transmit ethos. Reach out to me if you’d like to know more.