Multi Factor Authentication and Mobile Application Management roll-out

Project role: Project Manager 

Project intro:  Multi Factor Authentication (MFA) and Mobile Application Management (MAM) are IT security capabilities for protecting user accounts and their data. MFA is a very common and effective barrier against attempts to steal user’s passwords. MAM is a method for protecting corporate data on mobile devices (corporate and BYOD) where corporate users sign in. These two capabilities were to be implemented for all O365 E3 licensed users across the entire organization. In total, approximately 1800 users spread across 6 continents both onshore and offshore. 

Business case:  The business case was supported by three main benefits deemed necessary for the company: 1) securing the organization against phishing attacks, 2) protecting corporate data on mobile devices while at the same time increasing productivity on mobile devices and 3) enabling users to self-reset their passwords without Service Desk support.  

Technical setup – the legacy and the new: In the old setup, accounts were protected only by the user’s password. Furthermore, O365 apps were accessible from any location. This allowed for flexible remote work and collaboration, however it opened up for potential access to IT criminals should they learn a user’s password. The new setup should allow the same flexibility however it had to remove the associated risks.  

The solution leveraged on the existing Azure AD and Enterprise Mobility + Security agreement with Microsoft for implementing Azure MFA and MAM via Intune. Add-on implementations were the Azure AD Password Protection functionality and the Self-Service Password Reset.  

The AD Password Protection is a measure for increasing the quality of passwords selected by users while at the same time preventing commonly used and easy to hack passwords.  

Self-Service Password Reset (SSPR) is quite self-explanatory. Whenever a user forgets his/her password they have the option to pass a challenge by answering one or more security questions. If these are answered successfully then the user can proceed with creating a new password. All this without the necessity of contacting Service Desk. SSPR is beneficial to implement and roll-out together MFA since SSPR can use the same information for authenticating users.  

The implementation of many of these functionalities are very well documented on Microsoft’s learning portal – all in great detail. MFA and MAM can be configured in the Azure portal and will generally result in two access policies: one for MFA and the other for MAM. The involvement of the IT Security department in the creation or review of these configurations will ensure that the policies will meet the IT Security’s objectives for the organization. There can be many different scenarios to consider and all of these should be carefully analyzed with relevant project stakeholders. Here are a few example questions and scenarios:  

• When should users be prompted for the second authentication? 
• What should the MFA registration process contain? 
• Should users who have not registered for MFA be blocked from accessing resources remotely? 

• Which applications should be protected by MAM? 
• Which platforms (iOS/Android) should be allowed by MAM? 
• Should users be allowed to copy data out of the corporate accounts? 

• Etc.  

Once created, these policies can be internally tested on a few users before enabling these to larger sets of users.  

For enabling these policies to particular populations of users it is recommended to create two separate enablement groups for each policy (for example MFA_enablement_group, MAM_enablement_group). These are basically two security groups to which the respective access policies are applied. When a user or group of users are to be enabled for MFA and/or MAM they can simply be added to the relevant enablement group and the access policies will take effect for that new user.  

Having the MFA policy applied will not be sufficient to activate the MFA functionality to a user. Users will need to go through an MFA registration process which can vary depending on the configuration of the MFA policy. In our case a user could chose to register with their phone number, the Authenticator app or both from any location and any device. Once a user has registered for MFA and the user is also added to the MFA enablement group then the user will be able to pass the second authentication challenge prompted by Azure MFA.  

What should then happen if a user does not register for MFA after a given time period? Our option was to add these users to an additional “block” policy which would prevent them from signing in to their corporate O365 account from outside the client’s corporate network. Secondly, the “block” policy would allow MFA registration only from within the corporate network. These measures were taken to protect the accounts enabled for MFA but not yet registered.  

As soon as we approached the completion of the roll-outs it became apparent that we also needed an automatic process for enabling the MFA and MAM policies to new users and to have this enablement integrated into the onboarding process. For doing this we had to prepare a PowerShell script which ran daily and screened for new users. If the new users fulfilled the conditions for having the policies applied then they will be sent an automatic email regarding MFA and MAM. The script would also check if users enabled for MFA have not registered within a given time period (eg. 7 days) in which case they would be added to the “block” policy and informed automatically via en email. 

Project Management:  As mentioned above, the technical implementation was straight forward, especially with the help of our implementation partner and our new MFA & MAM admin. Having the policies created, the remaining challenge was to convince users to register for MFA and to openly adopt the new solutions.  

Even when the technology is perfect, it can still fail if the adoption is unsuccessful. This required more change management than initially anticipated. Our strategy was to raise awareness and highlight the benefits brought by these changes. We have done this through a number of campaigns using Yammer, Teams live events, trainings and emails. Communication coordinators were involved in preparing a communication plan and the various handouts. Finally, special training was given to Service Desk, Local IT and also to the executive assistants to have an easier reach and support for the Executive Leadership Team.  

The roll-out was planned into 3 geographically distributed waves (Asia-Pacific, Europe-Africa-Americas, Offshore). Prior to these 3 waves, we have conducted a pilot roll-out across all our IT functions. This was a great opportunity to get feedback from the users on the communication side but also to rehearse with the roll-out team. Improvements were made after each roll-out. Depending on the size and culture of the company it may be beneficial to distribute the roll-out waves not by geography but by organization (eg. Finance, Operations, etc.). If Management buy-in is easy then the organizational focused roll-out is better since a message from each organization head would be sufficient for increasing roll-out awareness. However, if some organization are very much spread out geographically you may end up with roll-outs covering all 24 time zones which may be more difficult to organize and manage. There are advantages and disadvantages to both.  

Having clean data sets about the users is very important in creating and managing the roll-out waves. We have use Microsoft MIM for pulling user data (eg. office, department, internal/external, job level, etc.). Likewise, the status of the MFA registration of each user can be pulled from Azure. These two data sets can be combined for creating lists of users pertaining to the specific waves but also for gathering intelligence on which users are pending the registration. The list can be then used for targeting the communication of an individual wave and sending out reminders only to those who actually need the reminder.   

Lessons learned: 

1. The project was much more a change management exercise than a technical implementation. A communication resource must be allocated to the team! 
2. The whip is better than the carrot! Meaning that users respond better to deadlines than to extended periods of time where they can register freely. 
3. The user guides must be simple and easy to follow. Nevertheless, you will not get the user guide perfect the first time so rather make improvements after each roll-out instead of waiting for creating the perfect guide first.
4. Keep your essential stakeholders close. For a project of this nature you need to have IT Security (they approve the policies), Legal Compliance (they approve data collection and processing depending on the chosen security policies), Service Desk (they support you during the roll-outs), CISO (for nudging the executive leadership to prioritize the project at company level), Communication (they provide communication coordinators)