One of the main difficulties faced when deploying a multi-factor authentication solution (MFA) is to define the “optimal” form factor. For a given level of security, you would like the solution to be both convenient and universal – that is, to cover as many use cases as possible, for as many users as possible. This is a question we’ve thought about for a long time at inWebo because organizations are so diverse and constantly changing, and we’ve been challenged by our customers to propose future-proofed MFA strategies.

Smartphone-based MFA is great, but…

Let’s say for example that the service you’re trying to protect is a federation server managing authorization for both behind-the-firewall and SaaS applications. Depending on who the users are, where they work from, and with which devices they access the applications, you may want MFA to be totally seamless and “tokenless” by leveraging web browsers as authentication credentials keystores. This works best when users always access from the same set of desktops, tablets, or laptops because, although minimal, there’s an initial registration procedure for a browser to be used as a keystore, so it may become cumbersome when users keep changing devices, or impractical if devices are shared or public. Or you may want MFA to leverage smartphones, with contextual and out-of-band authentication requests pushed to the users so that they confirm access. This alleviates the need for registering browsers, hence enabling true mobility. However, this requires all users to be equipped with smartphones, which is a very strong assumption for employee-facing applications as well as for consumer-facing applications.

Non-optimal segmentations

So, in most real-world deployments, smartphone-based MFA (such as inWebo Authenticator or mAccess) is best for some users – or situations – and tokenless MFA (such as inWebo Helium) is best for the others. Also, that segmentation varies all the time. Indeed, if we’re speaking of employee-facing applications, you probably have the possibility to correlate with which devices you have equipped which users. How cumbersome! And if we’re speaking consumer-facing, you have no clue. Finally, what’s good for today’s applications is probably irrelevant for next year’s.

So no choice appears ideal or future-proofed, hence the dilemma mentioned in the introduction. Should you give up the idea of MFA, scale back to cumbersome and poorly secure SMS-OTP, or make a choice that will leave out users and load the hotline? Hopefully none of these!

Always-best-authenticated thanks to a platform approach

Discussing these situations with our early customers, we have designed flexible solutions where authentication connectors (APIs) provide an “always best authenticated” feature: the same user will be given the easiest option to authenticate, tokenless or out-of-band, in any given situation. Our authentication platform works the same way as payment options do for an e-commerce, e.g. accept checks, Paypal, debit and credit cards. If your payment gateway accepts them all, you’re sure not to leave any customer out, but also that customers can choose the method that they have with them or are the most comfortable with for any given transaction. However, you still define policies and may decide that checks aren’t allowed for carts above 500 dollars.

For example, Alice may therefore use her browser token (inWebo Helium) when she connects to her VPN from her tablet, and use her smartphone (inWebo Authenticator) when she connects to her Office 365 account to check her emails from the hotel business center’s desktop. And she can get the new smartphone she’s authorized to every 18 months as per the corporate policy, without ruining your MFA deployment. It’s seamless from Alice’s perspective. It’s also seamless for her company IT admin since he doesn’t need to keep track of the devices she’s equipped with, or to define a static, unique way of authenticating. Your IT admin now has an easier job: he defines authentication policies, which may differ from service to service, or from group of users to group of users. A policy basically lists acceptable authentication methods, that is, the authentication options a user will be proposed, as in the payment options example.

All this is possible because inWebo platform has been designed and built with a multi-device, user-centric approach that abstracts the credential (authentication methods) management.

Try inWebo solutions for free, and talk to us about your authentication challenges!

The odds are that you were first exposed to some form of advanced authentication as an employee when you were given a key-chain token to connect to the company VPN or webmail, or as a customer when you received a code in a short text asking you to confirm a transaction. Although these look like completely different technologies, they have exactly the same single purpose: ensuring with the least possible error that a returning user of a service is the initially enrolled user. If they share the same goal, then why are Enterprise and consumer multi-factor authentication (MFA) so different? Is this going to remain so?

Different starting points

MFA appeared roughly at the same time as remote connections to corporate networks. Paradoxically, although cybercriminals hardly existed, it was inconceivable for large organizations to give access to their IT without some strong form of security, ‘strong’ meaning ‘hardware-based’. Enterprise MFA (at that time a tautology) therefore established itself as a sophisticated but quite expensive technology that equipped a fraction of the staff of large organizations.

In contrast, when the World Wide Web became a mainstream phenomenon and it became possible to pay or to move money online, identity fraud skyrocketed. However, online business was growing even faster, making identity security concerns an important discussion topic – but not yet a market. In 2007, when I started to brainstorm an authentication startup project that later on became inWebo, consumer MFA wasn’t even a concept. Authentication was based on passwords and free.

Explaining different trajectories

As the Enterprise MFA market expanded and started to attract more suppliers, differentiation built itself on price. Clones of RSA sprouted. The arrival of feature phones and early smartphones soon disrupted that market, making sound MFA possible without hardware. As a result, solutions improved both in terms of price and convenience (real security was downgraded at the same time, this is the subject of other posts).

Given the opposite starting points of Enterprise and consumer authentication solutions – the latter being free and hardly secure -, consumer MFA initially focused on increasing security but also on keeping costs as low as possible, actually far lower than what Enterprise MFA suppliers were charging. Therefore Enterprise-like solutions weren’t deployed on the new consumer MFA market – with some exceptions here and there. A few inexpensive options, such as printed code cards (TAN) or hidden paths never found adoption since neither brought enough security for the extra costs and friction they introduced. So the first real take-off of consumer authentication was brought with mobile phone generalization that allowed service providers to send one-time codes in short text messages.

Why consumer and Enterprise MFA may be converging

A lot of MFA-enabling technologies – such as smartphones, applications stores, html5, push notification frameworks, IaaS and PaaS platforms, but also biometric sensors on smartphones – are now widely available. Like any other software, MFA can therefore now be provided “at no cost” (beyond R&D, QA, operations, marketing & sales, corporate…), since MFA providers no longer need to manufacture and ship hardware devices, or to buy short texts in bulk from carriers and brokers. This allows for more flexible pricing, which now meets most service providers’ very low willingness to pay.

Furthermore, most of IT is now consumerized: employees are consumers to start with, they use web and mobile applications for both professional and personal reasons, most of the time from the same devices. Authentication should be no exception, there’s no obvious reason not to consumerize it too.

So it looks like MFA solutions have reached an “operating point” – consisting of pricing, security level, and friction level – meeting the expectations of both MFA markets, Enterprise and consumer-facing. Are therefore both markets merging?

And why they won’t

Branding requirements and corporate culture – yes, culture – are likely to keep the two markets separate for some time still.

It’s totally common and fine to show IT providers to employees, because IT is just a tool for most organizations, not a goal. The IT department’s objectives are no longer (if they ever were?) to develop in-house applications, but to select, integrate, and support the best tools for the business. Let’s say it: it’s now more cool to use well-designed vendor-developed Apps than the usually clunky corporate ones. MFA is no exception here.

In contrast, online providers build their products. Having a customer use a third-party provider to authenticate is not only a culture and branding clash, it’s also – whether or not there are good reasons – considered to trigger trust concerns.

Also, sectorial compliance and regulations faced by service providers in some verticals – in particular those likely to be most needing MFA, such as banking, payment, healthcare – makes it difficult for Enterprise MFA suppliers to enter consumer MFA market segments, in particular with managed solutions running in the Cloud.

A common platform to reconcile them

Recognizing the convergence of the “operating points” but also the reasons why Enterprise MFA solutions still didn’t fit service providers, inWebo developed an MFA solution. But not only an MFA Solution, inWebo also built an MFA platform.

A platform has no UI (user interface), it has APIs and SDKs (things developers like). Organizations not wanting to develop around an MFA platform use a ready-built MFA solution based on the platform, while service providers (and system integrators) use MFA platforms to build customized and branded MFA solutions, without having to reinvent the wheel. The wheel means in this case, among other things, (1) to dive into cryptography; (2) to integrate all new mobile platforms, OS, and web browsers; (3) to leverage smartphones and other devices’ capabilities as they appear, such as biometric sensors; (4) to design a secure lifecycle authentication credentials; and (5) to support multi-device and multi-service enrollment and recovery. An MFA platform is a fairly heavy and complex wheel.

The MFA platform approach – pioneered by inWebo in 2011 – is therefore removing the distinctions between consumer and Enterprise MFA and blurring the frontiers between both markets.

The time of the Business of Identity has arrived. From an obscure technical topic a couple of years ago, Identity and Access Management (IAM) has gained visibility from CIOs and other C-level executives. Since IT has become central both as a tool for employees and as a way to build and to provide services, IAM aims at organizing interactions with employees, as well as customers. IAM brings a user-centric approach – and therefore more agility and efficiency – to the delivery and orchestration of services, both for internal and external users.

IAM = Processes + Compliance + Security

IAM projects are also an opportunity to improve compliance and security. The former, because they allow an increased visibility by organizations on access rights, helping determine who did what when, in particular when something went wrong. The latter, because they are a way to enforce security policies, define who should have access to what when, and how a person accessing a service proves she’s an authorized user.

IAM is indeed about processes, compliance, and security at the same time. Whichever was the reason that first triggered an IAM project within an organization, the two others should be included in the same project. So, let’s say you’re a system integrator helping organizations revamp their IAM. How will you make it happen on all 3 aspects? To start with, should you really address these 3 aspects? If so, how many vendors should you talk to?

How MFA fits in IAM projects

Let’s focus on security. Identity security is provided by authentication. The good news is that the roles and interfaces between IAM solutions and authentication solutions are clearly defined. Schematically, an IAM solution acts as a provisioning and authorization server, while an authentication solution enforces access security policies. Both talk with each other using standard protocols, for authentication as well as provisioning. Most IAM vendors have integrations with most MFA (multi-factor authentication) vendors, and vice versa. At this point though, native MFA options proposed by IAM vendors are rather limited (the symmetric is also true), so you might have to consider specialized vendors for each component.

Authentication is a key component of IAM projects, and MFA vendors are well integrated – if not ‘OEMed’ – with IAM vendors. All this should encourage system integrators doing service around IAM solutions to also have MFA in their service portfolio, in order to cover the complete scope of IAM projects.

Partnering with inWebo

If you recognize it too, why is inWebo a partner of choice to provide MFA? First, for their product, which meets and exceeds most customer expectations, be it for its security level, its ease of use, or the vast number of real-world use cases it supports. You’ll also have a direct access to our Product and R&D teams, and we make sure to keep some capacity for customer projects in our next development sprints. Second, for their expertise and dedication to support you in marketing, selling, and delivering security projects. Third, for their commitment to the channel and partnership model.

See inWebo as a way to broaden your service portfolio. Our Partner team is there to help you generate more business.