Any CISO who’s been around the block understands Erik’s words. So, let’s roll up our sleeves and get started by understanding the scope of the problem.

Understand Needs

The first step in any security project is to be sure you have a clear inventory of your asset and applications. Everything flows from them. For most, this isn’t a small thing to do, but it is a necessity. From your assets, you can begin a risk analysis and business needs analysis. Mary Gardner expresses this step well: “Understand your various user groups and their risk profiles when rolling out MFA in a healthcare environment is very different than in a financial services environment.” This means honing in on your critical applications, looking at the major attack campaigns going on, and checking how well your current password authentication system can withstand these attacks.

You should look at key internal processes such as new employee roll-out (What credentials are provisioned and how burdensome is that process?), remote access solutions in-use (Which users are remote and what do they need to do?), and the pipeline for new apps and services (What will you need to deal with in the near future?). All of this can give you an idea of what and where you will need to focus your efforts. This is also important strategic information that you may need to build, explain, and justify your budget. As Mary says, “Be transparent about why MFA is being implemented—communication is key.”

Prioritize Which Apps Need MFA

It’s rare that a CISO ever gets to start fresh, so you’ll need to figure out how to integrate MFA into a live environment full of services that your customers and users depend on. Most people aren’t bold enough to flip a switch and convert every password login to MFA at once. The wise move is to pick and prioritize the deployment. Luckily, you should have enough information to rank who and what goes first and when. As Mary says, “MFA should not be required for every login unless the users or apps are high risk.” There are going to be some obvious candidates for MFA like remote access, administrator access, and anything involving compliance. Some apps will be on the fence, like e-mail, but in general, there can be significant threats and impacts with it.

One thing to reconsider is the apps and services that may be low-value to your organization. These same app services could be valuable to attackers and thus subject to exploitation. For example, unauthenticated or weakly authenticated services like memcached servers or IoT devices can be subverted by attackers to create DDoS weapons of immense magnitude. So even if there is little threat or impact to your organization directly, it’s worth considering locking access to these services to organization-owned IP addresses, which counts as a second authentication factor (something you are) in my book.

Work for the Users, Not on Them

Both of our advisory CISOs agree: begin with a pilot. Erik notes that “It’s imperative to run a pilot to find out what you missed in your project plan.” Mary adds that you should “Pilot the solution with key business partners.” The pilot users should know the MFA deployment is in beta and there will be mistakes and oversights. This is why you need to be transparent regarding the process, so users are aware of what is happening, what to do, and where to get help if things fail. In addition to the basic MFA processes of provisioning and revoking access, make sure these other key processes are nailed down, as well:

• Handling excessive failed logins and account lockouts
• Locking and replacing lost or stolen MFA tokens
• Managing software upgrades that may break the MFA process
• Providing emergency and urgent access for critical users when the MFA system is offline

Before pushing your MFA program out, you’ll need to have your story straight for all the users. Erik recounts, “We started with ‘the why’ and a marketing campaign to get the message across to our employees why we were turning on MFA.” Note what he said there: marketing campaign. Not an email. Not a short comment during the all-staff meeting. A marketing campaign that includes both of these things and much more. Use all the information you’ve gathered on the threats and criticality of the systems. Talk about how the MFA deployment will please customers and improve operational efficiency. Erik added, “We spent some time creating short videos, easy-to-access and consumable written FAQs, and a website to present it all. We used these over and over, and they proved critical to our success.”

Mary also suggests sweetening the deal by “Using MFA to roll out new functionality to users like Outlook Web Access and Office365; give the users some carrots.” Indeed, once you have a strong authentication system in place, powerful, easy-to-use application service models such as Google’s BeyondCorp can now be available for users.

Chose the MFA Solution that Works for Your Needs

All of this organizational analysis and user-centric work will pay-off when it comes to architecting your technical solution. You will know what you need and what resources you can spend to get it. On top of the security and integration capability of the solution itself, other key questions to consider are hardware versus software tokens, token supply, self-service portals, logging, and diagnostic capability. Erik looked at speed of deployment across a global company with thousands of users. “We needed to partner with our MFA vendor to ensure we had the technology dialed in. The sooner you can do this, the better.”

As the MFA deploys across your organization, remember even after the pilot, things will still go wrong. It’s just the nature of technology. Your MFA vendor and integration partners should be ready to help you with this. Mary also suggests, “Set up support functions as close to users as possible (rotating onsite helpdesks as you roll the function out).”

It’s Never Fire and Forget

Rolling out MFA is just the beginning. MFA should be monitored, nurtured, and adjusted. You should also realize that MFA deployments will continue to happen as upgraded token technology is available, new applications are introduced, and as new organizational units are integrated. Erik notes that “We learned many lessons when we rolled out MFA to our employees.” You, too, will have some stumbles as every organization is different, but you will learn from them as well. These lessons will come in handy as you tweak and upgrade your technology and processes.

As with any security control, you should also keep an eye on how well MFA is reducing your risk in comparison to its overall cost. Metrics on the threat reduction side include: failed login attempts, foiled phishing credential thefts, and denied privileged escalations. Every time someone else’s organization (not yours) makes headlines for a credential breach, it’s time to point at your MFA controls as a winning strategy. On the operational side, it’s helpful to keep an eye on the numbers of false positive failed logins (authorized user can’t get in), helpdesk call related to MFA, token resets, and failed tokens (hard and soft). To this you can add surveys, polls, and conversations with key app and business owners.

Now, Go Get ‘Em

Hopefully we’ve given you some useful ideas to pull off a successful MFA deployment. Like floppy disks, acoustic modems, and dot matrix printers, passwords are rapidly becoming relics of the past. If you haven’t rolled out MFA in your organization, there is no better time than now. As we’ve said before, start small, but most of all, just start.