I attended the Gartner IAM Summit in Vegas this week. Great conference, lots of smart and inspiring people. Multi-Factor Authentication (aka MFA or 2FA or 2-factor…) was a frequent topic of discussion, both in the analysts sessions, who did brilliant projections of the market trends – future, present, and past – and in the Access Manager vendors’ booths.
MFA is in the air! It’s hard these days to find any Access Manager that doesn’t come with some MFA features. 2 years ago, it was difficult to find any Access Manager with MFA. Why such a dramatic change? Is packaging MFA with IAM the ultimate approach, as opposed to a best-of-breed one? What are the pros and cons for both approaches from an architecture and a procurement strategy perspective?
MFA and access management – A short historical perspective
Disclaimer: I do Product for a living and I love inWebo MFA Product, so you’ve been warned: I’m probably not fully neutral on this topic. But when you read a blog post, you kind of expect an opinion, right?
Historically, MFA has been distinct from Access Management. Early on indeed, protocols separated access management from authentication, authorization, and accounting (aka AAA). Radius, then SAML, now OIDC have enforced this separation and vendors have stayed where they belonged, networking suppliers on one side, security vendors on the other side. Either the other side’s business looked too dull, or the pressure to grow quickly made everyone focus on his job, or maybe even there was some kind of a Yalta Conference where the big vendors divided the market, I don’t know for sure. But the world was simple. If you wanted a VPN you talked to Cisco, Juniper, and the likes. If you wanted MFA, you talked to RSA, Active Identity, and their clones. Prices and margins were high, innovation not a concern…
Alas, these good old days are gone. What happened? Many things for sure, but 2 main ones: SaaS and mobile. Applications fled the corporate network, many companies no longer have a corporate network. Around the same time, devices used to access applications proliferated. As a consequence, access management has been turned on its head.
The age of IAM – Part I – Not my business
The proliferation of applications and access devices brought a renewed interest for Single Sign-On (SSO). Sure, SSO did exist before, but you would mostly find it in web portals to provide a seamless navigation between distinct technical components of those portals – a kind of patch. The new SSO is meant to help users navigate without having to reauthenticate between applications and websites, mostly external, and in totally distinct domains. Fast forward: The originally simple SSO has grown to complex, feature-rich access managers, proposed by a new generation of vendors (or new business lines of old vendors such as Oracle, IBM, CA, and Microsoft).
Initially, however, the status quo has been maintained. Companies had a VPN in place, MFA was enforced there. the easiest solution – not optimal in terms of performance though – was to expose SaaS and web applications through the VPN for external users. Therefore, SSO didn’t have much to do with MFA. If you proposed to an Access Management vendor to integrate with an MFA solution, they would look at you strangely. It was not their business at all.
Part II – Not your business
Things have changed again around 2013-14. For a number of reasons combined with the proliferation already mentioned, access managers have increasingly been used for Internet-facing applications, both for users in the corporate network and outside.
VPN users were a fraction of the workforce, whereas application users are almost everyone. VPN aren’t cheap, a design status quo therefore became an expensive option. This is one reason for the change. Another reason is that applications have facilitated the move by supporting federation protocols, thus delegating authentication to access managers. Etc.
Following this change in the architecture, Access Management vendors started to get requests from their customers, mostly large organizations, to enforce MFA on the SSO. Indeed, when the first authentication is also the last one, it better be secure. Vendors were pragmatic: to cover a new area of expertise where they don’t have skills or components, they acquired or partnered. Microsoft acquired PhoneFactor; CA acquired Arcot; Ping, after initially partnering with inWebo, changed its mind and acquired Accell, Salesforce acquired Toopher. These vendors have then built their own MFA offering based on the acquisition (except maybe CA, but this is another story). Other vendors have partnered, such as Forgerock, SailPoint, or OneLogin. Some have built their own solution from scratch. Some have maintained a mixed approach, offering both an in-house solution (built or acquired) and third-party solutions.
The only common thing between all these approaches is that all Access Management vendors now support MFA. And actually, if you approach an Access Manager vendor with a new MFA solution, proposing a partnership, the odds are that they will look at you strangely. It’s their business that you’re talking about.
IAM and MFA – What comes next
So, did you make your choice, best-of-breed or packaged? Don’t expect me to give a single, definitive answer. Here’s why.
If you’re a large organization, there are good chances that MFA and IAM don’t cover the exact same perimeter of applications and users, and that your procurement cycles for MFA and IAM are distinct. For these reasons, you want IAM vendors to support your MFA solution, initially and later on when you upgrade your MFA to keep up with the fast innovation in this field. Indeed, large organizations favor a best-of-breed approach. Sometime this is not even to get best-of-breed solutions, but this approach is the only one possible to avoid duplicate investments in MFA. Interoperability is a must, packaging doesn’t work.
If you’re a small or medium organization coming to IAM for the SSO part. there are good chances (statistically) that you initally don’t see MFA as a strong requirement. Eventually, if you feel compelled to get it (because you operate in a regulated industry? because you’ve heard about it? because you’ve been personally using it with you bank? …), you’ll probably appreciate that it comes fully packaged with your IAM solution. IT resources are limited, so why spend them researching something that’s available in the package. MFA? Check!
There are other organizations, irrespective of their size, who get interested in the topic for itself. MFA is an area of fast innovation. Think that not so long ago, the only acceptable way (for security people) to implement MFA was to provide hardware tokens to employees and implement authentication servers in the company’s infrastructure. Now, most MFA solutions are SaaS and mobile, i.e. software. However, if you look at them from a security perspective, they are extremely different: implementation matters. Writing software for an Access Manager and for cryptography algorithms are totally distinct skills. Security is only one aspect. Given the pace of innovation, MFA is a product per se. If you do that as a side gig, you’re rapidly out of the game. If you want to be serious about it, you quickly realize that you need to maintain dedicated Product and R&D teams. For these reasons, specialized vendors tend to be far better than in-house developed MFA solutions (I don’t know of any exception but can’t exclude that they exist).
I told you, I don’t have a definitive answer. The size of your organization, its legacy, recent acquisitions, and many more factors may lead you to consider MFA in a packaged flavor or in a best-of-breed one.
A wise compromise for IAM vendors seems to be to both propose a simple in-house MFA solution and support third-party ones. An even wiser solution because it relieves IAM vendors from the burden of maintaining dedicated teams on the topic – while still giving them a net margin for MFA, and therefore an increased EBIT – is to replace their inhouse solution with white-label OEM ones. I bet we will see this soon.