Multi-Factor Authentication (MFA): Enterprise Strategy and Market Assessment

Multi-Factor Authentication (MFA): Enterprise Strategy and Market Assessment Published 25 January 2019 Abstract Multi-Factor Authentication is gaining traction as a best practice for enterprise security programs. It is based on the premise that traditional, single factor authentication schemes (like IDs and passwords) are relatively easy to break and as threats escalate, simply not good enough. It is a good time to consider making MFA a cornerstone of your enterprise IAM infrastructure given improved MFA vendor offerings and the inherent weaknesses of phishing-vulnerable password-based authentication. Requiring multiple factors from different categories for high risk or high value transactions is the emerging security best practice standard. A great MFA strategy consists of utilizing multiple sources of identity along with a set of business rules and information that can dynamically identify the degree of certainty of a user’s identity, while also being convenient to the user. This report starts by looking at the basic components and use cases for MFA, then evaluates the types of MFA approaches currently being deployed, the impact of MFA on the enterprise and provides a review of our short-list of vendors and solutions. We also leverage our consulting experience in providing a pragmatic checklist or starting point for organizations looking to architect, prototype, build/source and deploy an MFA solution for their enterprise. We then conclude with a set of recommendations and next steps.

Authors: Doug Simmons Gary Rowe Principal Consulting Analyst CEO / Principal Consulting Analyst [email protected] [email protected]

John Myracle Sorell Slaymaker Principal Consulting Analyst Principal Consulting Analyst [email protected] [email protected]

Multi-Factor Authentication Simmons, Rowe, Myracle & Slaymaker

Table of Contents

ABSTRACT ...... 1 TABLE OF CONTENTS ...... 2 EXECUTIVE SUMMARY ...... 4 INTRODUCTION ...... 6 WHAT IS MFA ...... 7 THE CONTINUING EVOLUTION OF MFA ...... 8 Initial Identity Vetting ...... 9 Early MFA; Token FOB for Remote Access ...... 10 Soft Token OTP ...... 11 PKI Smart Cards ...... 11 The Introduction of the Smart Phone...... 11 Authentication Standards ...... 13 Biometrics and MFA...... 15 FUTURE STATE OF MFA ...... 16 PASSWORD DEPLOYMENT AND VALIDATION ...... 16 MFA ENTERPRISE REQUIREMENTS AND ARCHITECTURE ...... 17

ARCHITECTURAL PRINCIPLES ...... 18 TECHVISION RUNTIME AUTHENTICATION PATTERN ...... 22 DEVELOPING YOUR MFA STRATEGY ...... 24 MFA PLANNING CHECKLIST ...... 26 Proof-of-Concept ...... 27 Pilot Program and Phased Rollout ...... 27 Identity Data Records and Account Creation ...... 28 Solution-Specific Application Integration Example ...... 29 Enrollment Vetting and Issuing Credentials ...... 29 Federation ...... 30 MFA VENDOR SHORT-LIST AND REVIEW ...... 30 AUTHY / TWILLIO ...... 31 DUO SECURITY / CISCO ...... 31 FORGEROCK...... 32 GIGYA / SAP ...... 33 GOOGLE ...... 35 IDAPTIVE (SPIN OFF FROM CENTRIFY) ...... 36 JANRAIN (RECENTLY ACQUIRED BY AKAMAI) ...... 36 MICROSOFT ...... 37 OKTA ...... 39 RSA ...... 40 SYMANTEC ...... 41

YUBICO...... 44 CONCLUSIONS AND RECOMMENDATIONS...... 45 ABOUT TECHVISION ...... 47 ABOUT THE AUTHORS ...... 48

Executive Summary Multi-factor authentication (MFA) is one of the most active and important areas within information security and IAM today. For well over a decade, the use of passwords to authenticate has been suspect; in particular for high value transactions the use of simple, relatively insecure and often recycled, easily guessed or stolen passwords are not good enough. To be sure, one of the most sought-after pieces of personal identifiable information (PII) is the username and password; this is especially problematic in that individuals often reuse the same username/password combinations at multiple sites. Requiring other factor(s) to access valuable content or to conduct high-value transactions is increasingly required and is the focus of this report. Multi-factor authentication is a subset of the authentication market and is often evoked based on adaptive authentication or step-up authentication based on security policy and/or contextual data regarding the person requesting access. The challenge with MFA is to balance the need for security with ease of use. This balance is supported by the execution of policies that build on reliable contextual data to dynamically determine when MFA is needed and when single factor authentication is sufficient. Measuring the degree of certainty that a user is who they say they are will increase as more data from more categories are collected. The more data that are collected in support of the user’s request across the four ranges of what a person knows, who they are, what they have, and their history—the greater the degree of certainty. This is the basis for multi-factor authentication. MFA is critical in the area of fraud prevention, and identity theft is one of the most prevalent and harmful forms of fraud in existence today. Over the past few years, significant advancements in the ability to deploy MFA to wide ranging constituencies – from employees, contractors, business partners to customers have made it much more palatable for enterprises of all sizes and types to consider. With the advent of mobile device ubiquity and the willingness for end users to deploy apps on these devices, techniques such as ‘mobile push’ have gradually broken down the barriers of cost and complexity to deploy MFA. With that said, it is a good time to consider making MFA a cornerstone of your enterprise IAM infrastructure and start saying goodbye to the inherent weaknesses of phishing-vulnerable password-based authentication. Furthermore, as we begin re- architecting our enterprise environments to incorporate elements of Zero Trust, MFA becomes a critical piece of the ZT-puzzle. TechVision Research has been espousing the notion of ‘identity as the new perimeter’ for the last several years. Within this concept, it is actually “identity + device” that becomes the perimeter. In a ZT environment, the most critical facet of security is knowing who (or what) the end user is as well as the device being used to authenticate that user or thing. This is the new perimeter; this combination of coupling an identifier with something the user has with them (like a mobile phone). Without the appropriate deployment of MFA, the authentication function remains one of the – if not the, weakest link in the enterprise and it is incumbent upon the enterprise security leadership to close this gap.

While other, more ‘legacy’ types of MFA such as One Time Password (OTP) tokens and smart cards still have a place in the IAM ecosystems for certain high-risk environments such as defense, finance, health-care, and IT administration, they can be considered deprecated in most enterprise situations. That is not to say they are no longer needed, but in many instances, the new age of mobile device-based MFA is more convenient and sufficient in many use cases to improve identity verification upon system login. Caveats to be considered of course include the actual ubiquity of mobile devices and network coverage/reliability in your environment – but in most cases, these caveats are in the minority. In this report, we provide a checklist to help you gauge your readiness and can go a long way toward ensuring that you’ve prepared your lines of business and your infrastructure for deployment. Like all things IT: the better you prepare, document your use cases and ‘user stories’, involve your key stakeholders, select the right vendor/tool for the mission and roll-out your services in a controlled, well-governed manner – the better your chance for success. Critical to enterprise success is the ability to measure levels of identity assurance and to do anomaly detection of abnormal access attempts. With that as the backdrop, this report identifies the leading business drivers effecting MFA adoption in both the enterprise and consumer-facing use cases, reviews the various types of MFA available, provides best practice insights for MFA deployment and reviews a short list of vendors who are leading the MFA revolution with their offerings. In short, we are looking to provide practical advice and guidelines for architecting, designing, building and deploying your future- state MFA program.

Introduction Cyber threats are becoming increasingly sophisticated and include a variety of techniques that involve guessed, hacked, or physically or virtually stolen credentials. These threats expose the inherent weakness within traditional username/password-based authentication schemes. Accounts that have been compromised can create even greater damage as individuals use the same credentials, or a limited pool of credentials to authenticate and access services across multiple sites. Increasingly elaborate large-scale data breaches are directed towards extracting replicated/repeated login credentials. What is needed is a means to mitigate the sharing of usernames and passwords and limit damage if they are compromised. Integrating Multi-factor Authentication (MFA) as a secondary or even tertiary security measure requiring an ‘out-of-band-channel’ to complete authentication. MFA makes it harder and more expensive for bad actors to compromise an organization. Bad actors can gain access to user names and passwords by: • Brute Force – Phishing thousands of users, hoping one will make a mistake • Targeting – Going after a specific user and trying to brute force guess their username and password, getting an associate to divulge this information, video surveillance such as a hidden camera or using their smart phone to record you logging in. Keystroke loggers fit into this category • Purchase – Buying user information from bad actors such as an electronic health record that has personal information such as a user’s social security number, address, phone number, work place, health procedure and emergency contacts The greatest risk of stealing someone’s account information is in the process of creating or modifying the account, especially password resets, change of physical address or change in mobile phone number. Enterprises should ensure that extra steps in support of identity protection are taken when account information is being modified. In light of these threats and attacks, organizations are positioning multi-layered authentication as a fundamental capability for increasing the protection of digital assets and TechVision believes this is a prudent strategy. The pervasive approach is to integrate a second and 3rd security layer employing additional factor(s) before authenticating and/or providing access to resources as defined within enterprise security policies. As more and more people interact in the digital world through online banking, online healthcare and education, remote enterprise access and so forth, they often need to submit highly sensitive personal or financial information via the Internet. Given this effect, the need for ensuring data privacy and protecting personally identifiable information (PII) has also become critical. Data privacy has become the focus of the international community and is reflected in the various governmental data protection laws and privacy regulations. From a regulatory perspective, the legal obligation to ensure compliance with all of these laws is left for interpretation by an organization’s Legal Counsel. In short, even when viewed outside of the international body of

governing privacy law, virtually every organization has some level of data privacy and protection responsibility. Preventing unauthorized or unintentional (e.g. accidental and fraudulent) access or release of an employee’s, customer’s or patient’s financial, health, and other forms of confidential and sensitive PII or business information is a key strategic security underpinning. Providing access security measures at multiple-layers at an infrastructure and policy-level will be needed for complying with future privacy initiatives. These privacy initiatives continue to advance, build, and evolve, at state, federal, and international levels. In summary, there are a number of factors driving the need for adding additional levels of security to the existing logon credentials currently in use. They include enterprise goals of: • Ensuring that the user or thing is who they say they are, • Facilitating equitable and reliable access for all employees, business partners or customers from anywhere, • Preventing unauthorized access to sensitive enterprise data ranging from trade secrets to an individual’s account commensurate with protections postulated by Risk Management, • Preventing unauthorized or unintentional release of sensitive corporate data and individuals’ personally identifiable information, financial data, and other stored data, and • Satisfying the organization’s dedication to the goal of protecting its data and ensuring privacy.

What is MFA Multifactor authentication can be defined as the use of more than one set of credentials from multiple categories that are used in concert to better determine (hopefully unequivocally) that you are who you say you are. Typically, one category of ‘factors’ is something that you know, such as a user ID and password. A second factor that is added to this is often something that you have, such as a smart phone, smart card, token fob or other such unique device that when paired with the first factor (something that you know), increases the veracity of authentication. A third factor can be incorporated as well – something that you are. Biometrics typically fill this bill with digital representations of your face (facial recognition), fingerprint, retina scan or voice print. Fourth is something that you have done. This can include where you have logged into from before (IP network address), recent transactions, time of day, last password reset, and flags for multiple failed login attempts To be clear MFA includes a minimum of two factors from at least two of the following four categories; 1) something you know, 2) something you have, 3) something you are, and 4) something you have done. It is often invoked when there is a high value transaction or there is a

risk of a breach, but it’s overall use is increasing. The risk profile could be raised based on activities such as multiple password attempts, the use of a new browser or the detection of a new geographic location not previously associated with the user. While most systems and services still use the traditional user ID and password combination (i.e., single factor authentication) as the primary means to access online systems, this is rapidly changing as most enterprises are (and should be) examining stronger authentication approaches including MFA. The Continuing Evolution of MFA It has been recognized for the past few decades that single factor authentication was often a risk, especially when the user is accessing sensitive applications and data. The use of MFA was limited especially in working with customers/prospects (note that even a single factor is often too hard to remember given the multitude of sites in which individuals are asked for ID/Password credentials). The widespread use of single factor authentication given usability concerns about more complex solutions has created barriers that have limited, or at least delayed, the widespread adoption of MFA. Two relatively popular mechanisms for deploying MFA – or at least 2FA over the past thirty years are 1) Public Key Infrastructure (PKI) with smart cards using X.509 certificates and 2) Keys or one-time-password (OTP) tokens that functioned as the second factor. These approaches provided the something you have (smart card or keys/OTP), in addition to a user ID and password or personal identification number (PIN). While these two popular approaches were relatively successful in raising the authentication veracity bar, they were (and still are) expensive and complex to deploy and can be difficult to use. Plus, these methods do not guarantee 100% user identification. Many enterprises add MFA and then get lazy. For instance, if a bad actor gets the user name and password, and then calls the help desk to get a new OTP token. To scale MFA and gain the associated security benefits the industry requires a more pervasive solution across a broad user base that is less expensive, easier to use and simpler to deploy. The good news is that we are getting closer to ‘MFA for the masses’ as we’ll cover in the vendor section later in the report. The confluence of mobile phone adoption along with along mobile applications that communicate with enterprise MFA servers, provide the ubiquitous platform for serving up one-time ‘password codes’ or to facilitate biometric integration like facial, fingerprint and voice recognition. This is ushering in a new breed of MFA solutions from both startup vendors and large industry platform providers including Google, Microsoft, DUO Security and Authy – to name just a few.

As we describe the evolutionary path towards pervasive MFA in the following sections, be aware that there is still no magic pixie dust that allows MFA to be deployed without a well-thought-out strategy that weighs the risks, costs and usability. The good news is that we are moving in a direction in which MFA is more cost effective and deployable across a broad spectrum of use cases – both internal enterprise and consumer-facing. But an enterprise MFA strategy must consider the association between authentication cost and risk reduction as described in the following figure:

Figure 1: Enterprise Authentication Decision Points

Initial Identity Vetting Before we get into the specifics of MFA, we need to start with an understanding of identity vetting, as evoking MFA on a suspect identity is like closing the barn door after the horses have escaped. Identity must be vetted before issuing credentials and is generally the first step towards establishing the requisite level of confidence that the authenticating user is in fact who they say they are. The appropriate level of identity vetting upon credential issuance is a key function of Enterprise Risk Management. In other words, the level of identity verification must be commensurate with the level of risk associated with the IT asset to be accessed. The strongest MFA technology could be deployed by an enterprise, but if the initial identity vetting process is weak, the entire authentication topology is weakened, as well. Please bear this fact in mind as we progress through this report and ensure proper attention is given to a strong vetting process. This may include initial in-person vetting with multiple forms of documentation for individuals that may be accessing high value assets.

We’ll now look at how MFA has progressed over the years while understanding that many of the early technologies are still being actively used today. And, as we mentioned earlier, there are many organizations that don’t even use MFA today for many use cases, but this is rapidly changing. Early MFA; Token FOB for Remote Access The primary early MFA approach was initially called two-factor authentication (2FA) and generally used a token FOB for remote access to systems via corporate Virtual Private Networks (VPNs). The pioneer in this space, starting in the mid-1990’s was RSA with their SecurID ‘token’, a fob that generates a one-time password (OTP) periodically (e.g., every 30 seconds) and is synchronized with a remote access server (RAS) supporting the VPN. This rotating, synchronized password method makes OTP solutions impervious to replay attacks, which is one of the key vulnerabilities of the ‘static’ passwords so widely used. These solutions work with the end user using the one-time password provided by token fob to authenticate to the corporate VPN – along with their user ID and associated password. This relatively simple method of enabling 2FA ‘back in the day’ worked wonders for many (primarily) large and distributed organizations. There are some factors that limited the impact of these early 2FA approaches as follows: • Access to the VPN via 2FA didn’t mean single sign-on to the corporate intranet – it simply let a person access the network. The applications running on the network would need to be integrated in order to support single sign-on via an application front-end such as a Web Access Manager (WAM) – which typically would only support User ID/Password. • The token fobs were relatively expensive– typically in the $45 per user range, so it was a significant expense item and required additional scrutiny and corporate expense if they were lost (or stolen). • The seed algorithm used to generate the synchronized one-time passwords on fobs and servers was not as secure as had originally been thought. In 2011, RSA’s SecurID platform had been breached at Lockheed-Martin – a major U.S. Defense contractor. While this could have been truly catastrophic for RSA, they worked diligently to replace the fobs, better secure the seed algorithm and recommend to its customers that they beef up their own password policies to strengthen the security of the UID/PWD and OTP combination. • Variations on the SecurID token fob theme have since emerged. For instance, Yubico offers a small USB token with an embedded chip that creates an OTP when a key is pressed and simulates a keyboard to facilitate easily entering a long password. Since it is a USB device it avoids the inconvenience of battery replacement. Additionally, versions of OTP technology have been developed that embed a keypad into a payment card of standard size and thickness. The card has an embedded keypad, display, microprocessor and proximity chip.

Soft Token OTP As we said earlier, token fob OTP solutions (and virtually all these early MFA programs) have not gone away and are still in relatively widespread use today – particularly in higher security environments such as government defense contractors and similar entities. However, in the early 2000’s it was recognized that the cost, deployment and management of hardware tokens in support of OTP were in many cases overly burdensome. In response, vendors such as RSA, Entrust, Gemalto and others developed software tokens that could be stored on general-purpose electronic devices such as desktop computers, laptops, or mobile phones. Because software tokens are something one does not physically possess, they are exposed to certain threats based on duplication of the underlying cryptographic material - for example, computer viruses and software attacks. Both hardware and software tokens are vulnerable to bot-based man-in-the-middle attacks, or to simple phishing attacks in which the one-time password provided by the token is solicited, and then supplied to the genuine website in a timely manner. Software tokens do have benefits over hardware tokens: there are no physical tokens to carry, they do not contain batteries that will run out, and they are generally less expensive than hardware tokens. Many enterprises have deployed ‘soft tokens’ as a way to improve authentication, but enterprises recognize and consider efforts to mitigate the potential threats we just described. PKI Smart Cards In the 1990’s, PKI was expected to reach the masses. X.509 certificates issued to individuals holding credit card-sized smart cards that contained a cryptographic chip. Similar to OTP token fobs, the smart card constitutes something you have, and when authenticating to a system with a smart card reader, the card holder enters a PIN (something you know) to enable the authentication process. In a nutshell, the challenges with deploying trusted certificates to large numbers of end users, coupled with supplying card readers on virtually every desktop or laptop the end users would access was costly and complex. Cards were lost, certificates needed to be revoked and reissued, Certificate Authority (CA) servers were needed, certificate revocation lists (CRLs) maintained and so forth – leading to a slow adoption rate that has since petered out even more. The Introduction of the Smart Phone While vendors were making hay with the SecurID token fob and soft token approach of the day and the attempts at large-scale PKI smart card authentication continued, the world was quickly ramping up rabid adoption of smart phones. While earlier ‘dumb cell phones’ supported short message service (SMS) text messaging in the mid-late 90s and early 2000’s, the advent of the iPhone and Google’s Android mobile device operating system spurred the smart phone revolution and the term ‘texting’ became a household word. Secondly, cellular network providers were rapidly improving SMS reliability and range. The combination of these two factors brought the smart phone into the fold as a bona fide ‘second factor’ – or ‘something you have’ that could obviate the need for a specialized token fob OTP generator or smart card for many organizations. This sequence of events was the real harbinger for widespread adoption of MFA within organizations of all sizes as well as the consumer and e-commerce site interactions.

This wasn’t lost on the financial community, as banks – needing to develop newer and more accurate ways to ‘know your customer’ (KYC) as mandated by regulatory groups guiding them, began to deploy MFA in the form of text messages with OTP ‘codes’ embedded in them to their customers’ phones in order to enable a key second factor to the authentication process with online banking – your UID, password and the code just sent to your cell phone on record in your account profile. This method of using SMS text messages to send OTP’s to customers and enterprise users is still very much in vogue today. It mostly works and works well, with little up-front investment for the customer, employee or enterprise. It does, however, disregard those users who may – heaven forbid – not own or don’t, at run time, have access to a cell phone. So, let’s consider the ‘80/20 rule’: if (at least) 80% of the users being addressed own a cell phone that can be reached quite readily from the OTP code generator, then the other 20% (or less) will have to be supported some other way. Often times, this is where the Security organization will mitigate risk by a number of additional defense-in-depth approaches. Generally speaking, the overall risk posture was improved – even with the 80/20 rule being considered. The greatest risk is using a mobile device and associated SMS message is when this device is lost, stolen, or broken. In this case the user may still need access, but another method of authentication will need to be used. In the process of getting a new device, a bad actor can imitate a user. And that bad actor can leverage social media to gain insight as to when a user goes on vacation and can subsequently work with the help desk to get their credentials and send the SMS password to a different phone number. Thanks again to social media, data of birth, city of birth, high school, favorite pet or pet name, … is all available to add to the “something I know”. But the major phone vendors have helped support the MFA movement. For example, Apple released the Apple Push Notification service (APN) back in 2009 and less than a year later Google released its own Google Cloud to Device Messaging service (C2DM) for Android devices. A ‘push notification’ is a message that pops up on a mobile device. Push notifications look like SMS text messages and mobile alerts, but they only reach users who have installed an app on the device to receive the messages. Typically, the end user receiving the MFA push notification on his or her device must ‘push’ a soft button on the display that means they acknowledge the fact that they are logging into an online system. Because the person with the phone (something they have) must be the same person logging into the online system with their UID/password (something they know), the end result is 2FA. Simply adding the requirement to provide their fingerprint (something they are) to this process-whether within the push app itself or by virtue of the smart device’s biometric capability, we can effectively deploy MFA.

This advancement in cellular messaging provided a big push (no pun intended) to make MFA much more user-friendly MFA. Along with Google and Apple, a new breed of MFA has vendor emerged; vendors that created MFA applications for iOS and Android devices as well as laptops running Windows and OSX. Companies like DUO Security and Authy quickly gained favor with enterprises in the MFA space because of the popularity of the tool with end users (including consumers) and relative ease of deployment and integration. Needless to say, legacy 2FA vendors like RSA adopted push technology in addition to their existing solution sets. Additionally, many IAM vendors that enable and support the authentication processes of their customers, such as Microsoft, ForgeRock, Okta, Janrain, Gigya/SAP and many others added push authentication capabilities to their products. As of this writing, the smart phone enabled push notification has emerged as the leading class of MFA solutions. While this approach isn’t perfect for all situations and certain high-risk use cases, it is very user friendly and readily integrated. There are some challenges as sophisticated bad actors can change caller ID. Close associates can see a new SMS on your cellular device when you take a quick break without knowing your phone login code or biometrics. Thus, the enterprise strategy should start with zero trust and then grant least privilege access based on level of identity assurance (or probability). Authentication Standards Authentication standards are emerging and should be considered as a starting point for an enterprise MFA program. For instance, the Initiative for Open Authentication (OATH) addresses authentication integration challenges with standard, open technology that is freely available to application developers. OATH is a collaborative effort of IT industry leaders aimed at providing a reference architecture for universal strong authentication across users, devices networks. Through an open standard freely available to all, it is intended that OATH will offer more hardware choices, lower cost of ownership, and allow customers to replace existing disparate and proprietary authentication systems whose complexity often leads to higher costs. OATH’s framework components are designed to be interoperable in solution development and deployment by enabling straightforward integration with existing identity and access management platforms and infrastructure (e.g. LDAP directories, web access management and single sign-on servers). The OATH standard, at a basic level, describes implementation of a core set of authentication credentials. These credentials are: • One Time Password (OTP) - based authentication • Public key infrastructure (PKI) - based authentication (using X509.v3 certificate) • Subscriber identity module (SIM) - based authentication (using GSM/GPRS SIM)

The OATH standard has been ratified in a series of IETF RFCs. Because OATH-based solutions can be compatible, migration between products is intended to become simpler and can leverage a much larger range of devices for OTP generation, such as YubiKey, and even sharing of hardware tokens between vendors. An important architecture goal for universal authentication is to enforce the separation between validation and identity stores. OATH recommends that all identities (user or device identities, as well as device-to-user bindings) be maintained outside the validation server. This separation is important from an integration and cost-control standpoint because it promotes a distributed architecture that favors the reuse of an enterprise’s existing infrastructure (e.g., corporate directories). In such architectures, the validation server is a minimal front end. OATH assumes that LDAP (including Active Directory and Azure Active Directory) is used to enable the validation server and the directory to exchange information. The OATH standard is currently being contributed to by a large number of vendors, including Gemalto, HID, Symantec, VASCO, Yubico and many others (please see https://openauthentication.org/members/), and is supported by a number of MFA vendors (discussed in further detail later in this document). Another important standard in the MFA arena has been developed and promulgated by the FIDO (Fast Identity Online) Alliance, an industry consortium launched in February 2013 to address the lack of interoperability among strong authentication devices (PayPal and Lenovo were among the founders). FIDO's aim is to support a full range of authentication technologies, including biometrics, Trusted Platform Modules (TPM), USB security tokens, smart cards, and near field communication (NFC). FIDO specifications provide two categories of user experiences, depending on whether the user interacts with the Universal Second Factor protocol or the Universal Authentication Framework protocol. Both of these FIDO standards define a common interface at the client for the local authentication method that the user deploys. The client can be pre–installed on the operating system or web browser. FIDO members totaled more than 260, including a Board made up of Aetna, Amazon, American Express, Bank of America, Gemalto, Google, Intel, Lenovo, MasterCard, Microsoft, NTT DoCoMo, PayPal, Qualcomm, RSA, Samsung Electronics, USAA, Visa, VMware, Yubico and many others. As we have learned over the past few decades, end-users thrive on standards – they do a lot of good in terms of fostering interoperability, reducing vendor lock-in and facilitating integration. The problem with standards is that there can be too many of them, and sometimes this dramatically reduces their ability achieve these objectives. TechVision Research feels that OATH and FIDO are the two premier standards in MFA technology development and vendors that incorporate either or both of these standards are better suited for most enterprise customers.

Biometrics and MFA Biometrics is an important element of the “who you are” category. Remember that at least two factors from two separate categories are required for MFA; the what you know is typically the user ID/password, the what you have might be your phone or smart card and the what you are is often biometrics such as facial recognition, your fingerprint, retinal scan, voice print or something else that is part of the individual. Biometric authentication has often been viewed as the ‘holy grail’ of MFA. Over the past three decades, there were numerous challenges in ‘early’ biometrics deployment and adoption topped by resulting in false positives and false negatives due to the early limitations of biometric readers and scanners. Given the recent investment, adoption and advancement of mobile device technology by vendors such as Apple, Google, Samsung, LG and many other smart phone manufacturers and operating platform providers, we have seen dramatic improvement in biometrics capability and reliability. Today, many MFA vendors can leverage the Trusted Platform Module (TPM) interface in these mobile devices to determine that the user had authenticated to their device via facial recognition or fingerprint biometrics and can incorporate this awareness into the overall strength of the end-to-end MFA session – leading to the elimination on the reliance of a user inputting a PIN (something she knows) and instead relying on biometric authentication to the mobile device as the second factor (something/who she is) in addition to possession of the device (something she has). Some biometric characteristics to consider are as follows: • Voice biometrics works well if a user calls on a regular basis and there is a long sample history. Voice biometrics needs a quality connection so that the voice quality has a mean opinion score above 4.0. Voice biometrics systems will return a probability score on how well the voice heuristics match that of previous samples. • Facial recognition works well for users signing into a device such as a phone, tablet, or kiosk. Recently, airlines such as Delta have added facial recognition to their self-service check-in kiosks to improve security and user convenience. • Fingerprints are used for secure access to systems such as Clear for airport security entrance identification. Iris scanning is another example, but is less prevalent because of the inconvenience to users, especially those wearing contacts. • Biometric systems can be spoofed, so they should be used in conjunction with other types of authentication. For instance, one can take 5 minutes of you tube video and create a voice or facial biometric print. We have all seen in the spy movies people chopping off fingers to get access to systems.

Future State of MFA We have anticipated the demise of password-centric authentication for decades. Our position is that this future is now or at least rapidly approaching. For the reasons we have been discussing – device and network ubiquity, reliability, Bring Your Own Device (BYOD) initiatives coupled with the accelerating levels of fraud associated with password-based authentication, the time has arrived to deploy MFA in your enterprise. As we discuss in greater detail later in this document, many large, influential vendors such as Microsoft, Cisco and others have laid down the gauntlet; they have drawn a line in the sand and have started shouting from the rooftops that the password is truly dead. Let’s be clear – the replacement of password-based authentication is an evolutionary process, as most consumers likely used usernames and passwords to authenticate to their networks or sites this morning - but simple IDs and passwords are about to become yesterday’s news – and fast. This is why every major enterprise needs to have a well thought out MFA strategy in place in 2019. The shifting of major IT infrastructures to the cloud via SaaS, PaaS and IaaS provide the opportunity to reinvent authentication – and that is what is happening. If your organization is migrating to Azure, there will come a time within the next 18-24 months when passwords are deprecated. Furthermore, as the concepts associated with Zero Trust continue to evolve and take hold, MFA will be an imperative. Will there be advancements over the next 3-5 years beyond mobile devices acting as the ‘something you have’ factor? Probably, but it won’t just be a more advanced phone as that factor; it could be your car, your watch, your house or many other “things” that haven’t yet been invented. There are a wide range of future combinations of things that can become MFA enablers – including biometrics that can be plugged into MFA. The key to being ready for this future is to start the journey now. Password Deployment and Validation MFA brings a new dimension to traditional IAM services. For decades, the onboarding process – whether spinning up an account for an employee, contractor, customer or thing has involved creating a username and password. The username is typically a primary key and is necessary to identify the entity digitally. That won’t likely change, but what about the password? The password has been a challenge from the start. Passwords are normally hashed using a number of differing hashing algorithms. Password synchronization has been a major undertaking when integrating disparate IT environments and platforms because the one-way hashing of passwords makes this very difficult - and in many cases impossible to migrate from one environment to another. This is an area that may impact your timelines and should be carefully planned out. Password policies are an absolutely critical part of any MFA program. Strong password policies require end users to change their passwords every 30-90 days and to create complex strings for passwords that include upper- and lower-case letters, special characters, numerals and so forth – and not reuse such a password string within 3 years. This is so hard for end-users and can be a

nightmare for administrators to manage. All of these factors contribute to a password-less future state. So, passwords will be forgotten and efficient processes for password resets must be in place. This is a major administrative cost for most organizations and should consider security risk, administrative costs as well as user satisfaction. Well though-out programs can help on all fronts. As an example, many call centers are utilizing phone numbers as one method of authentication and leveraging 3rd party services such as PinDrop to help validate the number. For instance, when there is a 95% or higher probability that this is the caller’s phone number, then the contact center agent will ask only 2 verifying security questions, instead of four, thus reducing the average call handling time by 20 seconds which also improves the callers experience. One gap many enterprises have is thwarting multi-channel identity spoofing. Bad actors will use the web, phone, and email to try and gain access. Or, some channels are not as secure as others. For instance, a bank allowed their customers to set up automatic credit card payments via an Interactive Voice Response systems (IVR). The IVR only required phone number and zip code to set up this feature. When one particular customer had his credit card stolen - with the name of the bank on the card, the thief looked up the users address and phone number. So, the thief would max out the credit card, call into the IVR and pay the bill, and repeat the process until the bank account was empty. Thus, a credit card that had a limit of $10K was used to drain a bank account with over $100K in it. This is an example of the challenge enterprises have in developing MFA programs and policies; while we stress usability and administrative cost containment, we must also systematically manage risks and regularly review and iterate based on new data. MFA Enterprise Requirements and Architecture So, we’ve just described the case for deprecating or minimizing the use of passwords while improving security. A well thought out MFA program provides the avenue upon which to begin this journey. An MFA program needs business stakeholder involvement and appropriate funding in order to be successful. Typically, and enterprise’s MFA program is driven by business needs such as — • Business Facilitation and the need to improve interoperability and efficiency through interconnected systems to support employees, affiliates, business partners and customers. • Enhancing User Experience by simplifying the process of authentication and letting the end user not have to remember another password. • Cost Containment planning to reduce the cost of management of multiple disparate authentication systems and processes. • Security Effectiveness and IT Risk Management improving the level of assurance that maps to an identity for appropriate authentication. • Support Administrative and End-user Efficiency and Effectiveness By consolidating the authentication infrastructure and better defining and reducing the number of access points.

These high-level business requirements are the basis for an MFA architecture per the following core foundational principles. Architectural Principles In principle, the organization should seek to implement a flexible, extensible, risk-aware enterprise authentication strategy that will accommodate current and future business needs and technologies. Typical future-state vision includes authentication services that— • Encompass risk-balanced user authentication to systems, networks, applications and services for the target users. • Support a strong user experience. • Address the full range of assurance levels identified by the organization along with associated requirements. • Support MFA from a suitably wide range of devices. • Provide authentication for the organization’s people, applications, devices and services regardless of platform and architecture. • Enable the organization’s business processes and workflows. • Ensure compliance and mitigate IT risks. • Are easy to use, sustainable and cost-effective. • Authenticate users for services and applications hosted both within organization’s networks and external to them.

With these principles as a backdrop, let’s look into the TechVision IAM Reference Architecture with our MFA glasses on. The TechVision Research Reference Architecture for IAM is this starting point; a master template, shown in Figure 2, below, identifies the IAM capabilities (rather than technologies) that can be improved or enabled, allowing business stakeholders and technical architects to achieve a common language for IAM functions, which can then be refined over time. This high-level template starts the journey:

Figure 2: IAM/MFA Master Template

The capabilities illustrated above are described at the highest level as: Interact – how end-users and application developers interact with the IAM platform. In the case of MFA, this will involve a variety of diverse people and technology interactions. Access – the rules that define the roles, rights, and obligations of any actor wishing to access enterprise or connected external assets. Change – the capability to define and manage the relationships between the user/ application developer and the enterprise assets. Manage – the capabilities required to manage and upgrade the IAM solution itself. Measure – the capabilities required to audit and improve IAM activities. Store – the capabilities required to share identity information and relationships between the components of the IAM solution.

The Reference Architecture’s second level is depicted in Figure 3, below.

Figure 3 - Second Level: IAM Portfolio Capabilities supporting an MFA program

As discussions progress into deeper levels of discovery, this master template organizes discussions beginning with the high-level interfaces associated with both end-user and application developer IAM service consumption. From either of these perspectives, organizations can navigate deeper into the runtime functionality requirements for: • Access (e.g., authentication, authorization, federation, privileged access, etc.). The authentication interfaces are where MFA interacts. • Identity lifecycle management (e.g., joiner/mover/leaver, change orchestration, and governance). MFA must be configured for end users and devices registered through identity lifecycle management interfaces. • IAM infrastructure administration, including MFA configuration and user administration. • IAM data management and reporting. MFA solutions provide various types of reports recounting user interaction, suspicious activity, performance and reliability statistics and so forth.

Once the required capabilities are identified, the next layer of the TechVision Research Reference Architecture for IAM allows us to explore each of the specific technology or process elements comprising each capability in the form of a combined portfolio architecture, as illustrated in Figure 4, below.

Figure 4 - Third Level: Elements of the Combined Portfolio Architecture

Time of Access Operations rely on Time of Change Operations, such as identity lifecycle management (identity registration, provisioning, workflow) and identity orchestration (identity correlation, synchronization, transformation) to provide contextual information about users and their current state, permissions, and entitlements. For example, an authorization system may implement the policy that a user must authenticate with MFA to be granted access to specific applications or services. An access policy enforcement infrastructure such as Policy Enforcement Points (PEPs) provides authentication of subjects – ranging from user ID and password to MFA. Some MFA tools are tightly integrated with services that provide authorization and reduced sign-on/single sign-on (SSO) through components such as policy decision points (PDPs) that make authorization decisions on behalf of PEPs. Because access policy enforcement systems usually support reduced sign-on/SSO, the centralized access services either proxy the access for the user, or generate Kerberos tickets, federation tokens, session cookies, or other session information that the resource can natively recognize. Web access management (WAM) services are a common solution set

consisting of PEPs (e.g., agents or proxies) and PDPs (e.g., authorization services) that provide centralized access policy enforcement and invoke MFA based on these policies. TechVision Runtime Authentication Pattern Users of any IT systems, whether employees, contractors, system administrators, customers, 3rd parties or technology suppliers must authenticate themselves before being granted access. We need to remember that MFA should be part of an overall authentication program and provide the right support and context for authorization decisions. Authentication may be in the form of: • User ID and password • One-time password token • Smart card • Biometrics We reiterate that for some systems, user ID and password will suffice, as long as there was proper risk management performed to determine the level of sensitivity and associated risk-of-loss of the data associated with the system. Also, password complexity rules, as defined by each organization’s Password Policy must be followed. As MFA solutions become more pervasive and are easier to use/deploy, organizations will move towards implementing MFA across the board contingent on budget and resource allocations. The timing will vary, but all organizations should at least be planning for an increased MFA footprint as this will be the future state. Once authentication has been achieved, authorization is the next step as decisions need to be made regarding the granting access to a specific IT or other assets. The following factors (and many others) can then be used to support authorization decisions: • Group membership in Active Directory, Azure AD or other sanctioned enterprise LDAP directory • Attribute values stored within the Identity Data Service (attribute-based access control, or ABAC) • Role values stored within the Identity Data Service (role-based access control, or RBAC) • Combinations of the above

But the hard part is putting this all together and making the right authentication decisions; keeping out threats while properly engaging customer, prospective customer and employees with the right access at the right time. The complexity and impact of these decisions have led to the concept of adaptive authentication as we’ll further describe below. The pattern covered in the following figure illustrates a consistent, uniformly applied, auditable and secure user runtime authentication and authorization future. Details of initial authentication may vary, but the point is that there is a policy-based decision that determines the required level of assurance given the current level of determined risk. This is referred to as ‘adaptive authentication’, in that the additional authentication factors that can be enabled via MFA are employed to attain that determined level of identity assurance.

Figure 5: Adaptive Authentication Service Pattern

The adaptive authentication service pattern illustrated above is summarized as follows:

• Multi factor Support o Support for OAUTH Tokens, OTP (SMS/Mobile Passcode generation), Voice, Push notification, Smart cards, hard tokens, etc. o Authorization of additional factor (device registration) • Inherited trust – leveraging an existing trusted device to extend trust to another device (addressing the lost device problem) • De-authorization • Risk-based Step-up Authentication o Collect additional environmental conditions to determine a current risk score o Trigger additional authentication factors in order to provide greater assurance of appropriate identity when risk threshold is exceeded • Identity Aggregation can assist in the on-demand collection of additional attribute information and environmental context from multiple sources for facilitating the risk evaluation As we highlight above, it is important to remember that MFA is a part of a larger set of policy and business decisions that should be carefully considered. The impact of these decisions can both impact security, but also the engagement and inclusion of people and things consistent with business goals. We’ll now examine this in the context of developing an enterprise MFA strategy. Developing Your MFA Strategy Thus far we’ve described the need for MFA, the challenges in the current models and our Reference Architecture for IAM with MFA. One of the goals with MFA and any security program is to achieve the proper balance between risk, investment dollars spent and ease of use. A big part of an MFA program is to set the policies and ensure the proper orchestration of when and how to implement MFA. It is also important to protect the data being used as additional factors in the authentication process - biometrics, personal questions to be answered and the like. One critical step is to identify the level of identity assurance required for data, application, and system access. Many organizations adopt a 4-tier model as shown in figure 6 below.

Figure 6: Four Levels of Identity Assurance

It is TechVision Research’s recommendation that organizations use a minimum of 2 factors for standard application access and that applications requiring higher levels of should add additional factors of authentication and rules such as: • Time and day of the week • Ticket for pre-approval • IP Address – In office, home VPN, Cellular, partner, or public network • History o Past access o Number of failed attempts o Last password reset o Transactions – Location, date/time, amount o Events A score can be created based on the number of MFA factors used along with history. If an account password has recently been changed or multiple failed login attempts, this can be used to detriment the score. As the old saying goes “if you cannot measure it, you cannot manage it”.

Creating a strategy of measuring identity assurance is important in an MFA initiative. For instance, a user requesting administration rights to a database should attain an MFA assurance score of 10. This score can be derived by requiring a help desk ticket with manager approval, validating the requestor based on their history, a window of time for access, only access from office or home VPN, along with MFA upon access. One reason that IT administration access needs to be highly secure is that this person also has rights to delete logs. While no system is perfect, creating a scoring system that quantifies privilege is a priority. There have been examples where someone is held hostage, or worse, by bad actors in an attempt to gain access to systems. TechVision will provide greater details in support of developing these scoring systems in future reports and, on a customized basis in our consulting engagements. At this point the reader should understand the basics of MFA, the value proposition and typical large enterprise requirements for MFA. But organizations should also assess their readiness for implementing a production-level MFA program. The following section describes key criteria for assessing the current state and prospects for success in implementing an MFA program. We’ve developed a checklist that looks at your enterprise MFA program throughout the lifecycle; from POC through deployment. MFA Planning Checklist This section describes a basic checklist or starting point for organizations looking to architect, prototype, build/source and deploy an MFA solution for their enterprise. We recommend that you read this carefully and use it to help you establish your MFA strategy and think about the basic design points. Like most things within IT, the deployment of new technology, such as MFA should generally require a proof-of-concept (POC) to establish your overall footprint, appetite for deployment and related characteristics that will help guide you to a smooth transition into production. It is also a good way of vetting a few short-list vendors - a “bake off” of sorts. We’ll start with the POC, but this will, of course, be subsequent to an evaluation process to develop a short list of vendors to be considered as POC candidates. After the POC we generally recommend a pilot and/or phased MFA roll-out followed by a thorough assessment and plans for how accounts are created and how identity data records are structured, stored and accessed. The next step is generally to begin to integrate applications and we provide an example. We then provide a checklist for the vetting of enrollments and issuing of credentials and finally provide some guidelines for how to best extend your enterprise reach (and offload some of the burden) via federation. These checklists leverage deep consulting work we have done in the MFA space and can offer a starting point for our clients. TechVision is, of course, available to provide deeper direct consulting services for our clients that would like additional assistance. We’ll start with the POC checklist by phase.

Proof-of-Concept 1. Does a plan exist (or has one already taken place) for conducting/performing a “proof-of- concept” demonstration for the MFA security plan/service anticipated for organization wide deployment? 2. Which MFA plan/service will be used during the proof-of-concept (basic/enterprise/platform)? Is this the same serviced planned for deployment? 3. How does the organization plan to announce, introduce, and train new users in the rationale behind the use of MFA? What online self-help materials will be made available? 4. What applications are scheduled for MFA protection during the proof of concept evaluation (are the most critical applications prioritized for moving first)? 5. Which users will be invited (remote employees, all employees, contractors, business partners, customers - those who need it the most) for enrolling and participating (what enrolment mechanism will be used - self enrolment, auto enrollment, or both?)? 6. Does the organization plan to request certain users to invoke “SMS” versus “Voice”, “one- time passcode”, or “Smartphone app” to exercise/examine each authentication process? 7. Does the organization intend to secure any landlines for voice enablement, deploy hardware tokens, and so forth? 8. Have you defined an MFA assurance scoring algorithm and determined what level of access is required to which data, applications, systems, devices, and users? 9. How will the organization determine success or failure for the POC? Pilot Program and Phased Rollout 1. What is your pilot program (initial/gradual rollout) strategy in terms of planned initial groups of users, size of each group invited, and associated follow-on group deployment (user migration plan for schedule/phased deployment)? 2. Do you have a plan for the order and schedule of applications (prioritized in terms of criticality) to protect with MFA? Does the rollout plan for the various applications align well with the user group migration plan? 3. What policies are in place/exist that address specific aspects of IAM such as network security or physical access cards? Which policies can be applied, or modified, to create a single inclusive and comprehensive IAM policy framework that will ensure MFA standardization? What inconsistencies or gaps exist within these policies and their related procedures? 4. What policies (e.g. users, devices, and networks) will be promoted during pilot deployment? 5. What are the expected minimum-security settings, to be eased in during initial MFA deployment, (e.g. failed attempts, lockout periods, etc.)? 6. What security settings will require tightening once MFA is fully deployed (or as rollout progresses)?

7. What other measures relating to initial provisioning access for resources and applications can be relaxed or simplified to afford a simplified MFA rollout process (maximizing usability while minimizing complexity and risk)? 8. What self-service/self-help features are identified for deployment (self-registration webpage, hosted training materials, etc.)? What IT actions can be pushed to the user to accustom them to being self-reliant (for example self-service re-credentialing)? 9. Are facilities for automating the provisioning and de provisioning of access contemplated for initial rollout? 10. Do you plan to involve Step Up Authentication in your deployment (in essence, a second form of verification after password authentication to enable a second factor of authentication)? 11. Do you have plans for implementing single sign-on (SSO) capabilities for reducing the number of multiple credentials (IDs and passwords) assigned to a user and enabling SSO through MFA? 12. Do you have a plan for eliminating existing silos of identity within the organization that force users to create and maintain multiple IDs? 13. How does the organization determine success for the Pilot/phased roll out? What needs to be in place prior to initiating a full roll out? Identity Data Records and Account Creation 1. Does the organization have a plan in place for creating a central person registry (master file) for combining identity data records (data consolidation and integrity checking ensuring data validity) across current existing disparate systems and for placing the authority at a single centralized office? 2. What data source(s) are planned for or involved for generating an Extract, Transform and Load (ETL, or bulk user import mechanism) file for bulk enrollment requests? 3. What methods and processes are contemplated for vetting, scrubbing, and proofing the currently existing identity data source(s) during enrollment? 4. Do you currently use Active Directory? How pervasively (how many domains)? Does your MFA strategy address a complex AD or Azure AD environment? 5. If more than one AD directory, what method or process will determine the primary or predominate directory source, or master registry file, for synchronization (managing overwrites of user data, non-unique names, and group conflicts)? 6. Has the organization identified backup enterprise directory servers for redundancy? What contingencies will be made available for users to access applications when the server is off-line or otherwise unavailable? 7. Do you have a granular approach for account creation and access decisions? To what extent can you automate the provisioning of user access based on affiliation, roles, and attributes?

8. How does the organization intend to verify that the individual user actually owns the phone/device (multiple devices) identified for sending PSMS verifications to and for verifying their email address ownership (landline, etc.)? Solution-Specific Application Integration Example 1. Do you plan for providing your own customized method for calling or texting (SMS) a phone number with a one-time PIN number? If yes, is a schedule in place for writing code to call to the API and testing the code? 2. Do you have any plans to programmatically integrate with the MFA solution’s administration capabilities such as, but not limited to, automatically accessing, reading, and acting on logging functions? If yes, what capabilities are envisioned and what metrics will be captured? 3. Have you identified and assigned team members to roles within the MFA administrative system (e.g. Owner, Administrator, Application Manager, User Manager, Help Desk, Billing, and Read-only)? Do you have a training plan and schedule in place? How will proficiency and understanding be measured for each member? 4. Have you identified any SaaS applications (e.g. Box, MS Office 365, SharePoint and other collaborative services) that you plan using MFA authentication service to protect one or more websites or applications via the solution’s authentication API? 5. Have you identified any cross-domain or inter-enterprise environments where you plan to implement an MFA access gateway? If so, which Identity Providers (IdPs), are involved (e.g. Active Directory, OpenLDAP, and SAML/OAuth/federated IdPs)? Enrollment Vetting and Issuing Credentials 1. Has the organization considered integrating the issuance of credentials with the in-person identity-proofing process during the physical identification card distribution process (e.g., corporate badges)? 2. Do you plan on making MFA a mandatory step during the registration process for employees, contractors, business partners, customers or and the like once deployed? 3. What processes are currently in place to establish and validate identity and issue credentials and how to streamline for reducing the time to activate an account? 4. How can the process and procedures (paperwork, etc.) for issuing of a physical corporate badge and the issuing of a digital credential be integrated for new employees or contractors? 5. If a user needs to change their phone number, how will that change be securely validated, or add a new device (for example when a phone is lost or stolen)? 6. How do you plan to manage users that do not enroll in MFA (e.g., require another ID check, Data Protection Act check, or remove account?)? 7. Do you have plans for providing an access account for use by pending employees and hiring candidates for use prior to their start or acceptance date providing limited access?

8. What about former employees/retirees? Are your benefits management solutions in scope for MFA? Federation 1. Have you identified all the peer organizations in the federated environment possibly being established with external providers, such as cloud service providers, partner sites and others? 2. What guidelines have you considered from the National Institute of Standards and Technology (NIST) and the federal government's Office of Management and Budget's Memorandum (and other established standards) for asserting your organization’s identities with externally-federated partners or solution providers? Will MFA authentication be relevant or required across these federations? The above checklist can be a starting point for mapping out your MFA program and to help ensure there are not areas that have been missed or questions you are not asking. This of course, will factor into your existing processes, infrastructures, legacy systems, security policies and best practices. In summary, we hope that this checklist provided you with some valuable insight into key considerations for the design, integration, roll-out, risk mitigation and training to be considered and to prepare for, architect and execute on your MFA program. These questions also exemplify how TechVision integrates our “hands-on” consulting experience with our research. We know that building an effective program is more than just an academic review (no disrespect to our education clients). A key takeaway is that MFA is a ‘high touch’ solution that involves end users directly – an enterprise can’t simply ‘flip a switch’ and turn on MFA. Thoughtful planning is a must – never forget Murphy’s Law and use these checklists as guidelines as you develop your MFA program. The most successful MFA programs are those that find the best balance between elegant user engagement and risk management. MFA Vendor Short-List and Review As we have described in this report, a great deal of investment and time has gone into developing many of the MFA solutions available on the market today. The investment continues as enterprises step-up (pun intended) their investments and MFA programs. While there are many factors to consider in evaluating vendors in this space, we’ll look to net out some of the key elements or each vendor’s program and direction in this short-list summary. The MFA strategy for a customer-facing internet-based commerce environment is often not the same strategy for an employee-facing solution and will vary widely based on privacy and

regulatory controls. What might be an excellent fit for one environment may be overly risky for another and every organization should start with an understanding of their current state, key requirements and target future state as we described earlier. With that background, TechVision feels that the following vendors (listed in alphabetical order) are strong candidates for consideration in that they address key enterprise MFA requirements and have a solid future state plan: • Authy (Twillio) • DUO (Cisco) • ForgeRock • Gigya/SAP • Google • Janrain • Microsoft • Okta • RSA • Symantec • Yubico Authy / Twillio Auhy was still an early stage company specializing in MFA prior to its acquisition by Twilio in February 2015. Since then, the company has gained consideration traction with its MFA product called “Authy”. Authy supports MFA by generating a time-dependent six-digit code, which the user enters after submitting a username and password. The Authy application facilitates the process of getting MFA set up with many online services such as Facebook, Amazon and Google. Typically, these services provide a QR code to be scanned into the app (in this case, Authy) that the end user is using to store MFA codes. Once completed, Authy will connect to the user’s account and generate unique codes to use whenever logging in. A key feature of Authy is the ability for users to access their data across different devices. Authy encrypts users’ data and stores that information in the cloud, with decryption taking place on the local device. Users’ actual tokens are never stored in the cloud, making it safer to pull their codes from multiple devices. In this way, Authy can work offline and end users can add new devices with SMS, voice or existing device approval. TechVision analysts have worked with several clients that have leveraged Authy and the results have been positive. DUO Security / Cisco DUO Security offers a cloud-based security service called Duo Access that provides second factor authentication for bring-your-own-device (BYOD) mobile environments such as smart phones and tablets. Duo’s solution verifies the identity of user and the health of their devices before granting access to applications. Since 2012, Duo has become one of the pre-eminent providers of unified access security and multi-factor authentication delivered through the cloud. In September of 2018,

Duo Security was acquired by Cisco, and it is anticipated that integration of Cisco’s network, device and cloud security platforms with Duo’s ‘zero trust authentication and access products will add to Cisco’s value proposition. We believe Duo’s technology is a strategic addition to Cisco’s portfolio and is in alignment with their intent-based networking strategy by extending it into multi-cloud environments and simplifying policy for cloud security and expanding endpoint visibility coverage. This is, on paper, a very positive acquisition for Cisco. Duo Push, sent by the Duo Mobile authentication app, allows users to approve push notifications to verify their identity. DUO supports Universal 2nd Factor (U2F), security keys and tokens, one- time passcodes (OTP), SMS and phone call-back to provide options for different types of users. Duo’s software as a service (SaaS) user self-enrollment method is augmented by automated enrollment options to potentially simplify user provisioning for larger organizations. Automatic enrollment can synchronize users from existing directories like Active Directory and Azure AD or import users from a CSV file. Additionally, users can manage their own authentication devices via a self-service portal. Duo allows enterprise security teams to launch targeted phishing simulations to identify vulnerable users and devices. Their data dashboards facilitate measuring and monitoring the risk of getting phished. Additionally, Duo’s Unified Endpoint Visibility enables tracking and reporting on all end user devices from a dashboard. This module provides data on user behavior and risky devices and allows useful search functions and integration with SIEM systems to help find vulnerable endpoints/devices, such as devices that have been rooted, jailbroken or other failed safety tests. Duo's Trusted Endpoints functionality can issue device certificates that are checked at login for insight into and control over BYOD environments and can limit access by any personal devices that don’t meet the organization’s security requirements. Duo also facilitates enforcement of role- based access policies based on an individual or group, or their specific roles and responsibilities. This feature lets organizations set customized policies based on authentication method on a per- user or per-group basis. Geographic location access control can prevent unauthorized access from any geographic location, as well. While Duo suggests its MFA solution can control privileged access and SSH (Secure Shell) access to specific internal applications and data centers instead of VPN access, their solution also integrates with major enterprise remote access gateway and VPN providers, including CA SiteMinder, Oracle Access Manager, Juniper, Cisco, Palo Alto Networks, F5, Citrix and others. TechVision analysts have worked with several clients that have leveraged Duo and the results have been positive. ForgeRock ForgeRock is an identity and access management software company that develops commercial open source identity and access management products for Internet of Things, customer, cloud, mobile, and enterprise environments.

ForgeRock offers a comprehensive IAM suite that includes a Web Access Management platform (OpenAM), Identity management/provisioning platform (OpenIM), an LDAP directory (OpenDJ) and an identity gateway/ API stack called OpenIG. ForgeRock also offers a Profile and Privacy Management Dashboard for compliance with the EU General Data Protection Regulation (GDPR) and provides support for the User-Managed Access (UMA) 2.0 standard. From an MFA standpoint, ForgeRock has been offering an SDK that can be integrated with its access manager, OpenAM for the past three years. While there has been some moderate uptake on this SDK with its IAM customers, ForgeRock has also developed a currently 50-company Trusted Partner Network, as we mentioned in the Symantec review. The ForgeRock Trusted Partner network includes leading MFA solution vendors such as Duo/Cisco, Symantec, Yubico and many others and fits well into their overall IAM platform. Rather than solely investing in its own MFA offering, ForgeRock leverages key partnerships to make available a wider range of MFA capabilities to its customers. ForgeRock’s investment has been leaning toward expansion of its access and identity management capabilities – notably its development of Authentication Trees to provide OpenAM with more granular capabilities when establishing authentication with an end user. Authentication trees provide fine-grained authentication by allowing multiple paths and decision points throughout the authentication flow. Authentication Trees are made up of authentication nodes, which define actions taken during authentication. In this way, important functions such as ‘step up authentication’ can be invoked, such as when an end user attempts to access an application or service that is deemed higher risk. In this scenario, the end user would be required to re-authenticate with a stronger credential, such as MFA, including FIDO 2 web authentication. Authentication trees can also factor in geo- location, device type, and additional data/insights to tailor the authentication experience to the end user’s current environment. Lastly, progressive profiling can be enabled to gradually add the base of user information each time that user log. This can help to establish a common, standardized view of the end user that can both be used to enable more seamless access capabilities and determine anomalies in user behavior that might trigger an alert. ForgeRock highlighted in their briefing with TechVision that they are ultimately cloud-enabling all of their software capabilities and are creating ‘turnkey’ solutions that are more easily deployed on their client’s cloud vendor of choice in highly available multi-zone Kubernetes clusters. TechVision has worked with several clients that have leveraged various elements as well as ForgeRock’s entire IAM suite with positive results. The authentication tree capability has just been released but looks promising and is consistent with our view that flexibility and configurability are key to balancing strong security with ease of use. Gigya / SAP Like Janrain, Gigya is a CIAM solution running on their Customer Data Center (CDC) cloud. Gigya was acquired by SAP in September of 2017 – forming a potentially formidable end-to-end shop floor-to-customer ERP/CRM/CIAM ecosystem for SAP customers. Because SAP has been lacking a bona-fide IAM solution that can extend beyond the SAP platform, the acquisition of

Gigya could lead to improved IAM capabilities for the SAP-centric enterprise, as well. TechVision has been involved in several briefings with our clients with SAP providing presentations and Q&A to discuss the strategic value and tactical programs supporting integration and plans/direction for future Gigya/SAP offerings. Gigya/SAP enables secure access to the Gigya CDC platform with an SMS-based one-time password (OTP) capability out-of-the-box. The company also partners with a 3rd party called SAASPASS in order to enable its MFA and SSO solution. SAASPASS can be integrated with existing Active Directory environments in order to leverage enterprise user accounts and groups for enabling B2E MFA. Similar to many of the other vendors we are covering in this report, end users (including customers) can download and install the SAASPASS app on their mobile devices and scan a QR code from the SAASPASS registration page to register their devices. When servicing B2E end users, SAASPASS administrators can enable applications for MFA from a menu list provided on the admin screen, as show below:

Figure 7: SassPass Administration Screen

The applications selected and configured for SAASPASS access then become MFA enabled and support SSO across these applications. SAASPASS supports RESTful APIs as well, in order to facilitate further application integration for MFA and SSO.

Google Google recently briefed TechVision on their MFA program and strategy. Overall we were impressed with their strategy and vision in the MFA and Identity space. Google started by describing cloud identity (IDaaS offering) and their intent to become a more mainstream IDaaS player. They also described their tiered MFA strategy staring with baseline security designed to minimize user and administration friction leveraging Machine Learning (ML) that delivers anti- hijacking protection and safe browsing. Then, for high-value users, they have a set of ala-carte offerings that provide deterministic MFA with support for the following factors in rough orders of assurance: • SMS/Voice • Backup codes • Google Authenticator (TOTP) • Google Prompt (mobile push) • Hardware U2F keys (Titan Security Keys) That is the broad vision Google has in the MFA space, but we’ll now look at a few specific areas. First, similar to what we described with Authy, Google Authenticator is a software token that implements a two-step verification service using a Time-Based One Time Password algorithm (TOTP) and a HMAC-based One-Time Password algorithm (HOTP), for authenticating users of mobile applications by Google. The Google Authenticator provides a six- to eight-digit one-time password that users must provide in addition to their standard username and password to log into Google services or other sites. The Authenticator can also generate codes for third-party applications, such as password managers or file hosting services. Previous versions of the software were open-sourced but subsequent releases are proprietary. The Authenticator application is downloaded onto a smartphone. To log into a site or service that uses 2FA, the user provides a user name and password and runs the Authenticator app on the mobile device, which displays an additional six-digit one-time password. Note that a set-up operation has to be performed first so that the site can provide a shared secret key to the user over a secure channel, to be stored in the Authenticator app. This secret key will be used for all future logins to the site. This is a pervasive, easy to use and highly scalable solution. While Google Authenticator’s OTP app has proven reasonably popular, the company last year added device push as another MFA option that can be sent directly to users’ Android devices as well as the Google client on iOS devices. This step can be considered as further acknowledgement of the device push techniques growing popularity among end users. Additionally, Google last year began selling their own USB/NFC and Bluetooth security keys under the “Titan” brand, based on the FIDO U2F standards that are similar to Yubico’s Yubikey hardware fob (reviewed further in this document). As part of Google’s growing presence in the IDaaS and cloud platform arenas, their Titan Security Keys are being positioned as their most secure MFA offering. To underscore this point, Google announced in 2018 that they have had no

reported or confirmed account hijackings after deploying Security Keys to their more than 85,000 employees. A key takeaway is that Google is not only providing services for their pervasive platform, but is also providing broad IDaaS and MFA services for enterprises through their Google Cloud business. Idaptive (spin off from Centrify) TechVision recently met with Corey Williams, the VP of Product Marketing at Idaptive. He explained that Idaptive has been split from Centrify and that Centrify is focused on Privileged Access Management (PAM) and Idaptive now has the IDaaS and MFA and analytics portfolio of services, although Centrify will also have some MFA capabilities associated with PAM. He explained that the overarching focus of Idaptive is Zero Trust and that MFA, IDaaS and their analytics platform are key foundational elements in support of a Zero Trust Architecture. The start by registering every device their environment and put a managed certificate on the device – used to provide ‘silent sign on’ to their workstation. Called Zero Sign On. They also Another key element of their program is adaptive sign on – set of rules to invoke when someone attempts to authenticate. The adaptive sign on doesn’t force the user to enter factors and they will also allow customers to write rules that don’t force MFA depending in the risk assessment. But, if, for example, there is a new application, a new location and/or a new device – this may prompt the user for additional factors. Idaptive has also added risk level metrics based on a user’s past behavior, using ML and AI to determine if this particular access attempt exhibits some risk. In terms of their future state, they will be adding more data and improving analytics in time, are partnering with Palo Alto Networks (data lake of enterprise behavior) and are investigating adding feeds of data from known breach services. Centrify and now Idaptive have been strong IDaaS and MFA vendors for the past several years. The main caution is some degree of uncertainty and possible delays as they sort out the synergies and overlaps with the divestiture. Janrain (recently acquired by Akamai) Janrain is a leading cloud-based Customer IAM (CIAM) solution deployed by hundreds of organizations and supporting hundreds of millions of customer end users. In late 2015, Janrain announced the addition of multi-factor and mobile password less authentication to their CIAM platform. Because of the customer-centric nature of their solution suite, Janrain focuses on streamlining account registration, reducing fraud and improving customer protection by adding MFA during the registration and login process, which further enables phone verification to improve account security, simplify account registration process and increase customer conversions to the Janrain CIAM platform. In addition to supporting authentication through SMS text passcode to the customer mobile phone, Janrain supports its mobile Push app that lets customer users respond to a ‘push notification’ sent to their mobile device in order to be authenticated, as illustrated below.

Figure 8: Janrain Push MFA

It was announced on January 7, 2019 that they were acquiring Janrain. Jim Kaskade told TechVision that this acquisition “confirms my thesis that CIAM will become more about security than marketing personalization” Akamai and Janrain described their initial roadmap integration to allow: • The combination of Janrain's Identity services with Akamai Bot Manager to increased accuracy in mitigating identity fraud - delivering superior detection with the lowest possible false positive rates. • Akamai to understand login history/access patterns (e.g. Geo/City/Time of the day/Device, etc.) to differentiate legitimate end user login attempts from bot-based attacks. • Akamai to offer better, more nuanced responses to potential attackers, including step-up authentication to enhance protection without compromising normal end user experience • Deliver a single digital identity that consolidates user context across all channels, social media and offline sources.

We’ll see how they execute as it is very early, but all clients considering Janrain should understand the advantages and disadvantages of this acquisition. Microsoft Microsoft Windows and Active Directory are deployed as the network operating system and directory infrastructure for most organizations around the globe. Microsoft were relatively early pioneers of the move to a cloud-based architecture for Active Directory (AD), Office 365, SharePoint, etc., establishing Microsoft Azure as its global cloud platform and quickly encouraging its customers to migrate on-premise deployments of these applications to Azure. In the past few years, a large number of its customers have migrated to Azure and this major shift to its multi-tenant Azure cloud continues at a rapid pace.

Microsoft introduced MFA several years ago, stemming from its dominance in the Network Operating System (NOS) directory infrastructure market with AD coupled with a relatively similar dominance in the office application market. The Microsoft MFA server was introduced in 2014 as an on-premise server integrated with AD. Not surprisingly, as the mass migration from on-premise AD and Office infrastructure to Azure commenced, the company recently announced it was going to discontinue Microsoft MFA Server as an on-premise solution and only offer Azure Multi-Factor Authentication (MFA) – a fully cloud-based solution. Azure MFA is of course intended to safeguard access to data and applications via a range of authentication method, including push to device, security tokens, biometrics, SMS text and voice. Microsoft’s Multi-Factor Authentication comes as part of the following offerings: • Azure MFA Service (Cloud) – This is the only Microsoft option for new deployments. It requires no on-premises infrastructure and can be used with federated or cloud-only users. • Multi-Factor Authentication for Office 365 - A subset of Azure Multi-Factor Authentication capabilities is available as a part of an Office 365 subscription. • Azure Active Directory Global Administrators – As a quasi-privileged access management (PAM) solution, a subset of Azure Multi-Factor Authentication capabilities is available as a means to protect global administrator accounts. The genesis for Microsoft’s MFA offerings stem from their acquisition of PhoneFactor nine years ago and providing MFA server support with voice, text, hardware and software tokens. Subsequently, Microsoft invested in this base code to eventually bring this solution to Azure. In our interview with Microsoft, they were adamant that the use of passwords is nearing its end. In the near future, the use of passwords to authenticate to Azure-based services will be deprecated in favor of MFA. While this may appear to be a bold move, we applaud Microsoft’s recognition of the inherent risks associated with passwords – and if any vendor can pull this off, Microsoft is one of the leading candidates. This may also be supported by Microsoft’s decentralized identity strategy TechVision will cover in a subsequent report. Biometric authentication is also supported by Microsoft, but it is device-centric as it relies on the endpoint device’s Trusted Platform Module (TPM). This means the end user’s biometric data will never leave the device – the end user authenticates to the device via its inherent biometric capability, such as fingerprint, facial recognition or voice print, and Azure MFA determines this to be the ‘something you are’ factor, coupling this with the possession of the device (something you have). In this way, the endpoint device becomes the ‘credential’. Per the following screen shot, Administrators can assign various authentication approaches per user or groups in Azure AD.

Figure 9: Microsoft MFA Method Selection Administrator Interface

It is noteworthy that Azure MFA administrators can assign the MFA type required to access systems and applications based on risk profiles of the systems being accessed, such as high, medium, low risk. Azure Microsoft MFA also supports adaptive authentication – for example, when navigating from Office 365 to SharePoint, the policy can dictate an MFA request of the end user. Additionally, Azure MFA “remembers” the way an end user logged in before, and performs that same flow in subsequent logins, utilizing Azure’s machine learning capability. Azure MFA also works with a number of popular commercial MFA solutions, including DUO, Authy, RSA, Google Authenticator Yubikey and many others – as long as they support the OATH or FIDO industry standards. Okta Founded in 2009 by a team of former Salesforce executives, Okta is a cloud-based identity and access management platform built on Amazon AWS. Okta was one of the first IAM solutions built ‘in the cloud’ from the ground up, rather than a cloud-instantiated on-premise solution suite. Their solution has gained a good deal of traction with enterprise customers over the past five years, as more and more companies look to migrate much of their IT infrastructure – including IAM, to the cloud. Okta’s Active Directory synchronization tool provides the primary mechanism for integrating on-premise identity information with Okta’s cloud directory. The integration between customers’ AD infrastructure and Okta provides SSO to the enterprise applications ‘front-ended’ by Okta, including a broad range of SaaS applications like Workday, SalesForce, etc. Okta’s MFA feature is an extension of their cloud IAM platform, and supports the following forms of authentication: • Okta Verify • Google Authenticator • SMS Authentication

• Voice Call Authentication • Symantec VIP • On-Prem MFA (e.g., RSA SecurID) • DUO Security • Yubikey • Security Question (generally NOT recommended) • Email • Windows Hello • U2F keys Okta Verify is an MFA factor type designed for end user identity verification with the Okta service. Okta Verify is available for iPhone, Android, and Windows devices. Okta Verify includes the option to deploy Okta’s MFA app to enable push notifications to these mobile devices. Okta Verify also supports Touch ID technology to guard against unauthorized use of Okta Verify. Administrators can configure an end-user fingerprint request, which appears after the initial MFA challenge. This feature is currently only available for iOS devices. For improved security on Android, Okta customers can enable hardware key storage on Android via Okta Verify Settings. Enabling this feature allows the implementation of security protocols using access-controlled, hardware-backed keys based on the Federal Identity, Credential, and Access Management (FICAM) architecture. Okta Verify for mobile also uses FIPS 140-2 validation for all security operations when enabled in the administrative dashboard. Okta addresses FedRAMP FICAM requirements by relying on FIPS validated vendors. Okta uses FIPS-validated vendors such as Apple and Google to ensure that Okta Verify and its backend infrastructure uses FIPS-validated technology. Okta’s FIPS implementation provides validated support for the following devices: • Apple iOS mobile devices running iOS 7 and higher • Android mobile devices running Android 6 and higher

For organizations that are already deployed in Okta, their MFA Push solution generally makes good sense to enable. RSA RSA is well known for its SecurID product that provides two-factor authentication utilizing hardware tokens, software tokens, and one-time codes. In 2016, RSA re-branded the SecurID platform as RSA SecurID Access. The RSA SecurID authentication mechanism consists of a "token" — either hardware (e.g. a key fob) or software (a soft token) — which is assigned to a computer user and which creates an authentication code at fixed intervals (usually 60 seconds) using a built-in clock and the card's factory-encoded almost random key (known as the "seed"). The seed is different for each token and is loaded into the corresponding RSA SecurID server (RSA Authentication Manager, formerly ACE/Server) as the tokens are purchased. On-demand

tokens are also available, which provide a token code via email or SMS delivery, eliminating the need to provision a token to the user. The token hardware is designed to be tamper-resistant to deter reverse engineering. When software implementations of the same algorithm (i.e., "software tokens") appeared on the market, public code had been developed by the security community allowing a user to emulate RSA SecurID in software, but only if they have access to a current RSA SecurID code, and the original 64-bit RSA SecurID seed file introduced to the server. Later, the 128-bit RSA SecurID algorithm was published as part of an open source library. In the RSA SecurID authentication scheme, the seed record is the secret key used to generate one-time passwords. Newer versions also feature a USB connector, which allows the token to be used as a smart card-like device for securely storing certificates. A user authenticating to a network resource such as a RAS needs to enter both a personal identification number and the number being displayed at that moment on their RSA SecurID token. The server, which also has a real-time clock and a database of valid cards with the associated seed records, authenticates a user by computing what number the token is supposed to be showing at that moment in time and checking this against what the user entered. RSA Authentication Manager from RSA Security is an MFA tool that adds additional security measures (via smartphones and biometrics) to standard username and password logins for a number of services and servers. RSA Authentication Manager is especially suitable for those organizations that want to make use of a variety of external SaaS products, such as Google Drive, Salesforce and O365. There are a number of authentication methods available, such as risk-based authentication, two-factor authentication, on-demand text messaging and tokens. SecurID is the token side of RSA Authentication Manager, and it handles the configuration of the individual tokens. RSA provides both SecurID hardware and software tokens. RSA Authentication Manager supports a wide variety of applications and use cases, including VPNs, Outlook Web App, Salesforce, SharePoint, Microsoft Internet Information Services and others. There is also a web agent, which can sit on a web server and direct authentication requests to the RSA Authentication Manager server. This expands an organization's ability to authenticate home-grown applications that aren't explicitly supported via other methods. Symantec Symantec is one of the largest and well-known security vendors. The Symantec Validation and ID Protection (VIP) Service is a multifactor authentication (MFA) product that uses biometrics and smartphones to supplement standard username/password logins on a variety of servers and services. The VIP platform was initially developed by Verisign prior to their acquisition by Symantec in 2010. Symantec has traditionally covered many categories of security capabilities; examples include Data Loss Prevention (DLP), Information Centric Encryption (ICE), Cloud Access Service Broker (CASB) and their Symantec Endpoint Protection (SEP). The company is attempting to tie these solutions/brands together via tighter integration across their product suite.

Symantec’s MFA solution is an extension of their VIP Solution (previously called Symantec Access Manager). Similar to Okta and Microsoft Azure AD, VIP is a cloud-centric solution that provides SSO and OATH-compliant MFA to B2E customers primarily. Symantec also told TechVision that they are making a market push into the B2C (CIAM) space, much like Microsoft, Okta and others. Symantec is using its broad range of security solutions to further enhance its MFA offering, extending beyond the ‘simple’ act of authentication to take into consideration the health of the device and the context of the authentication event (e.g., geo-location, etc.) – similar to Duo/Cisco and RSA approaches. As illustrated below in material provided by Symantec, VIP supports the following authentication schemes:

Figure 10: Symantec VIP Supported Authentication Schemes

Symantec VIP is also being positioned as a ‘better alternative’ to Microsoft MFA for Azure tenants.

Figure 11: Symantec VIP Being Positioned as Microsoft MFA Alternative

Symantec provides MFA integration with Azure AD and O365, while also offering endpoint protection and other integrated services beyond what Microsoft provides. Symantec is also planning to integration MFA policy configuration for VIP through the Microsoft Azure Administrative Console in order to support more MFA policy granularity. Similar to other MFA vendor offerings, VIP is provisioned to end users by having them scan a QR code to register their devices and enable the VIP app on the users’ mobile devices. It is important to note that Symantec adding to their B2E focus with a push into the CIAM space, offering VIP B2C so that its customers can better mitigate their own customers’ risk of account takeover and credential stuffing. With the acquisition of Life Lock and ID Analytics a little over a year ago, Symantec is becoming positioned to provide better visibility into identity verification as well as threat detection and analysis. VIP B2C utilizes “passive means” to determine risk to the/of the end user, such as incorporating network location, network configuration, malware, device fingerprint to prevent SIM swapping as part of VIP’s runtime risk analysis. These capabilities are being provided via an SDK, so that customer can incorporate VIP into their mobile applications. In December 2018, Symantec joined ForgeRock’s ‘Trust Network’, thereby enabling VIP to be a replacement for ForgeRock’s own MFA solution (discussed below) as well to leverage VIP’s threat detection and mitigation capabilities within the ForgeRock IAM ecosystem.

Yubico Founded in Sweden in 2007, Yubico manufactures a hardware authentication device – called Yubikey that supports one-time passwords, public-key encryption and authentication, and the Universal 2nd Factor (U2F) protocol developed by the FIDO Alliance. It allows users to securely log into their accounts by emitting one-time passwords or using a FIDO-based public/private key pair generated by the device. YubiKey the storing of static passwords for use at sites that do not support one-time passwords. Facebook uses YubiKey for employee credentials, and Google supports it for both employees and users. Some password managers support YubiKey. Yubico also manufactures the Security Key, a device similar to the YubiKey, but focused on public-key authentication. Illustrated below are some of the more popular USB-centric form factors for the Yubikey.

Figure 12: Yubico’s Yubikey USB Authentication Devices

Over the past year, Yubico has been working with Microsoft to further enhance Microsoft’s MFA on Azure. In particular, Microsoft worked with Yubico to further develop the FIDO 2 specification in order to move the ball toward true password-less authentication – one of Microsoft’s (and Yubico’s, among others) major objectives. For example, Yubikey, in combination with Windows Hello facial recognition establishes a strong root of trust that can enable end users to strongly authenticate even from devices other than their Surface laptop. Having a Yubikey removes the need to send SMS text OTP or an email with an authentication link when an end user accesses the environment from multiple devices as part of their normal course of work or commerce interaction. Yubikeys have also become popular as ‘backups’ for MFA when mobile phone ‘push’ doesn’t work for various, valid reasons such as mobile device ownership or network coverage lapses. Yubico has become a thought leader in the MFA space by being there early and developing many partnerships. Several vendors are working with Yubico to develop their own FIDO-centric

initiatives. Additionally, Yubikeys have become the primary replacement for RSA SecurID tokens with a cost-effective OTP alternative. Yubikeys can be purchased online at commerce sites such as Amazon and can be deployed independently of an enterprise-wide B2E (or B2C) MFA initiative. Conclusions and Recommendations MFA is rapidly becoming the default standard for authentication; the combination of increased scale, the lack of well-defined perimeters, increasingly sophisticated threats and improvements in MFA offerings are influencing this projected future state. MFA services are getting better, smarter and easier to use and that is accelerating a more wide-spread movement to MFA MFA is a key to fraud prevention and identity theft is one of the most prevalent and harmful forms of fraud in existence today. Over the past few years, significant advancements in the ability to deploy MFA to wide ranging constituencies – from employees, contractors, business partners to customers have made it much more palatable for enterprises of all sizes and types to consider. With the advent of mobile device ubiquity and the willingness for end users to deploy apps on these devices, techniques such as ‘mobile push’ have gradually broken down the barriers of cost and complexity to deploy MFA at scale. With that said, it is a good time to consider making MFA a cornerstone of your enterprise IAM infrastructure and start saying goodbye to the inherent weaknesses of phishing-vulnerable password-based authentication. Most organizations should at least be planning their future state with a heavy emphasis on MFA and supporting adaptive and intelligent authentication services. The timing is right for most enterprises to develop and/or update their MFA strategies as organizations are developing improved approaches to better locking down their assets. This includes re-architecting enterprise environments to incorporate elements of Zero Trust as MFA is a critical part of a Zero Trust program. TechVision Research has been espousing the notion of ‘identity as the new perimeter’ for a few years now. Within this concept, it is actually “identity + device” that becomes the perimeter. In a Zero Trust environment, the most critical facet of security is knowing who (or what) is the end user and the device being used to authenticate that user or thing. This is the new perimeter. Without the appropriate deployment of MFA, the authentication function remains one of the – if not the, weakest link in the network. While other, more ‘legacy’ types of MFA such as OTP tokens and smart cards still have a place in the IAM ecosystems of certain high-risk environments such as defense, finance and health-care, they can be considered deprecated in most enterprise situations. That is not to say they are no longer needed, but in many instances, the new age of mobile device-based MFA is more than sufficient to improve identity verification upon system login. Caveats to be considered of course include the actual ubiquity of mobile devices and network coverage/reliability in your environment – but in most cases, these caveats are in the minority. We strongly encourage our clients to examine and, where appropriate follow the checklist we have provided in this report to gauge your readiness. This can go a long way toward ensuring that you’ve properly prepared your lines of business and your infrastructure for deployment with minimal

friction and maximum user engagement. The lesson with MFA and most major infrastructure programs is that the better you prepare, document your use cases and ‘user stories’, involve your key stakeholders, select the right vendor/tool for the mission and roll-out in a controlled, well- governed manner – the better your chance for success. Good luck and let TechVision know if you’d like a dialogue or follow-up in the MFA area.

About TechVision

World-class research requires world-class consulting analysts and our team is just that. Gaining value from research also means having access to research. All TechVision Research licenses are enterprise licenses; this means everyone that needs access to content can have access to content. We know major technology initiatives involve many different skill sets across an organization and limiting content to a few can compromise the effectiveness of the team and the success of the initiative. Our research leverages our team’s in-depth knowledge as well as their real-world consulting experience. We combine great analyst skills with real world client experiences to provide a deep and balanced perspective.

TechVision Consulting builds off our research with specific projects to help organizations better understand, architect, select, build, and deploy infrastructure technologies. Our well-rounded experience and strong analytical skills help us separate the “hype” from the reality. This provides organizations with a deeper understanding of the full scope of vendor capabilities, product life cycles, and a basis for making more informed decisions. We also support vendors in areas such as product and strategy reviews and assessments, requirement analysis, target market assessment, technology trend analysis, go-to-market plan assessment, and gap analysis.

TechVision Updates will provide regular updates on the latest developments with respect to the issues addressed in this report.

About the Authors Doug Simmons brings more than 25 years of experience in IT security, risk management and identity and access management (IAM). He focuses on IT security, risk management and IAM. Doug holds a double major in Computer Science and Business Administration. While leading consulting at Burton Group for 10 years and security, and identity management consulting at Gartner for 5 years, Doug has performed hundreds of engagements for large enterprise clients in multiple vertical industries including financial services, health care, higher education, federal and state government, manufacturing, aerospace, energy, utilities and critical infrastructure. Gary Rowe is a seasoned technology analyst, consultant, advisor, executive and entrepreneur. Mr. Rowe helped architect, build and sell two companies and has been on the forefront the standardization and business application of core infrastructure technologies over the past 35 years. Core areas of focus include identity and access management, blockchain, Internet of Things, cloud computing, security/risk management, privacy, innovation, AI, new IT/business models and organizational strategies. He was President of Burton Group from 1999 to 2010, the leading technology infrastructure research and consulting firm. Mr. Rowe grew Burton to over $30+ million in revenue on a self- funded basis, sold Burton to Gartner in 2010 and supported the acquisition as Burton President at Gartner. John Myracle is a technical specialist/architect with a broad technology and diverse business background. Mr. Myracle combines knowledge of intellectual property with product conceptualization development and delivery. Experience includes communicating business, financial, and technical objectives between legal, sales, marketing, and development teams for banking, communications, optical transport network management, security, mobile, and medical device applications. Patent experience includes drafting 150+ applications and IP portfolio monetization. Mr. Myracle is a seasoned system/solution architect, product manager, and senior consultant with 35+ years’ experience at Booz-Allen & Hamilton, IBM, and Southwestern Bell Corporation. Core focus areas range from cloud computing and IoT to European Union GDPR compliance and smart contracts on blockchain. Sorell Slaymaker has 30 years of experience designing, building, securing, and operating IP networks and the communication services that run across them. His mission is to help make communication easier, cheaper and more secure since he believes that the more we communicate, the better we are. Prior to joining TechVision Research, Sorell was an Evangelist for 128 Technology which is a routing and security software company. Prior to that, Sorell was a Gartner analyst covering enterprise networking, security, and communications.

Sorell is an IT Architect with a focus on network, security, and communications architecture. He specializes in IT Architecture – Network Architecture, SIP Trunking, Contact Centers, Unified Communications, and Security Architecture.