The Enabling Technologies Blog

Scott Barr / / Categories: Azure, Security

Multi-factor Authentication (MFA) Tips and Considerations: Part 1

Let's face it, MFA is ubiquitous. We use MFA on a regular basis with personal accounts with our banks, credit card companies, personal email accounts, etc. I haven't heard any complaints about this. Yet, the moment we bring up MFA for corporate identities we suddenly believe our users cannot handle the pain -or- we get push back from users that it is too much trouble. 


Just like your organization must share the responsibility for securing and protecting its data with your cloud provider your users must also share the responsibility of protecting corporate data and assets with their employer. MFA is an excellent way to do both. 


Enforce MFA full time on high value targets like global administrators (GA), down-level privileged accounts, user accounts with access to sensitive corporate data - that which you deem most valuable. 


Let's focus on global administrators and other privileged accounts for a moment. 


  • Shared responsibility - Microsoft provides the means to secure your identities but it's up to you to configure them, use them, and practice security. You are responsible for protecting the GA accounts and your company’s data. 
  • GA accounts should be dedicated accounts - not every day user access 
  • Use cloud-based GA accounts, not synchronized 
  • GA accounts should be protected by STRONG passphrases 
  • Protecting GA accounts with MFA should be one of the first security protections you enable when creating your Office 365 tenant 
  • Microsoft's Secure Score lists it as the highest priority action and assigns 50 points for enabling MFA on all GA accounts - this weight is a strong indicator of the order of importance and has more weight than any other security action 
  • MFA enabled GA accounts can still use PowerShell to administer the following Office 365 services: 
  • Azure Active Directory (Windows Azure Active Directory Module & Azure Active Directory V2 PowerShell Module 
  • Use a Privileged Access Workstation (PAW) or make sure the system you are running PowerShell from is secure (don't be that admin that used a compromised system for privileged access) 
  • Create dedicated non-MFA enabled accounts for automation and use least privilege roles for automated processes 
  • Create a dedicated break-glass GA account 
  • Audit GA and other privileged account access 
  • Think end-to-end security 
Tags: Azure Security

Subscribe to Email Updates

Refine by

To expand the list, please click on the double arrows.


Search by Category or Author: