Using Multiple Authenticator Apps with One Microsoft 365 Account: Guide for MSPs

bp1

For Managed Service Providers (MSPs) with multiple employees managing numerous customer Microsoft 365 tenants, efficiently and securely handling multi-factor authentication (MFA) is crucial. While a single Microsoft 365 user account typically links to one primary authenticator, there are legitimate scenarios and best practices for MSPs to leverage multiple authenticator apps for a single user, enhancing both security and operational flexibility.

Why Multiple Authenticator Apps for an MSP User?

While the general recommendation for individual users is to have a single, primary authenticator app for an account, MSPs often encounter unique needs:

  • Redundancy and Backup: In case a primary device is lost, stolen, or damaged, a secondary authenticator on another device ensures access isn’t lost, preventing costly downtime.
  • Shared Administrative Accounts (with caution): While not ideal, some MSP workflows might necessitate a shared administrative account for specific, highly controlled scenarios (e.g., break-glass accounts). In such cases, multiple technicians might need access to the MFA codes, making multiple authenticators a practical, albeit carefully managed, solution.
  • Employee Transition: When an employee leaves, transferring MFA access to a new team member can be streamlined if a secondary authenticator is already configured on a shared, secure device (e.g., a dedicated company phone for administrative access).
  • Location/Device Flexibility: Technicians working from different locations or using various company-issued devices might benefit from having the authenticator configured on each frequently used device.

Best Practice Approaches for MSPs

The core principle for MSPs managing MFA is to prioritize security while maintaining operational efficiency. Here’s a breakdown of best practices:

1. Leverage Conditional Access Policies (Azure AD Premium P1 or P2)

Conditional Access is the gold standard for managing MFA in Microsoft 365, especially for MSPs. It offers granular control over when and how MFA is enforced, allowing for much more sophisticated policies than basic security defaults.

  • Granular Control: Define policies based on user groups, location (trusted IPs, risky locations), device state (compliant, hybrid Azure AD joined), application being accessed, and sign-in risk.
  • MFA for Administrative Roles: Always enforce MFA for all administrative roles (Global Administrator, User Administrator, Helpdesk Administrator, etc.) across all customer tenants.
  • Location-Based MFA: Require MFA for sign-ins from outside your MSP’s trusted network locations.
  • Risky Sign-ins: Automatically require MFA or block access for sign-ins detected as risky by Microsoft Entra ID Protection.
  • Device Compliance: Require MFA for access from non-compliant devices.
  • Prioritize Microsoft Authenticator: Encourage or enforce the use of the Microsoft Authenticator app for push notifications or number matching. This is generally more secure and user-friendly than SMS or voice calls.
  • Phased Rollout: When implementing or modifying MFA, conduct a phased rollout. Start with your internal IT staff, then move to pilot groups, and finally to all users.
2. Designate Specific Authenticators for Specific Purposes

Avoid a free-for-all with authenticators. Be strategic:

  • Primary Authenticator (User’s Personal Device): The Microsoft Authenticator app on the technician’s primary work smartphone should be their main MFA method. This offers convenience and strong security (push notifications, biometrics).
  • Secondary Authenticator (Company-Provided Device or FIDO2 Key): For backup or shared administrative accounts (used rarely and with extreme caution), a secondary authenticator on a company-issued device (tablet, spare phone) or a hardware security key (FIDO2) is preferable. FIDO2 keys offer the strongest phishing resistance.
  • Avoid SMS/Voice as Primary MFA: While useful for recovery, SMS and voice MFA are susceptible to SIM-swapping and other attacks. Limit their use as primary authentication methods, especially for administrative accounts.
3. Implement Break-Glass Accounts

Maintain a small number of highly secured “break-glass” or emergency access accounts. These accounts are exempt from normal Conditional Access policies and are only used in extreme emergencies (e.g., a global MFA outage, or if all administrators are locked out). These accounts should:

  • Be cloud-only (not synchronized from on-premises AD).
  • Have strong, complex passwords stored securely and offline.
  • Be monitored for any sign-in activity.
  • Have their credentials rotated regularly.
  • Ideally, use hardware FIDO2 keys for MFA.
4. Regular Auditing and Monitoring
  • MFA Registration Reports: Regularly review who has registered for MFA and what methods they’ve configured.
  • Sign-in Logs: Monitor sign-in logs for unusual activity, failed MFA attempts, or sign-ins from untrusted locations. Microsoft 365 Lighthouse (for CSP partners) and Azure AD reports can provide consolidated views across tenants.
  • Access Reviews: Periodically review administrative roles and MFA configurations for all users, especially for those with elevated privileges.
5. Training and Documentation
  • User Education: Train your MSP employees on the importance of MFA, how to use their authenticator apps correctly, and how to report suspicious MFA prompts.
  • Internal Procedures: Document your internal policies for MFA, including how to set up new authenticators, handle lost devices, and manage break-glass accounts.

Step-by-Step Configuration: Adding Multiple Authenticator Apps to a Single User

This process generally involves the user adding additional authentication methods through their security info settings. An administrator initiates MFA enforcement, and the user then registers their chosen methods.

Prerequisites:
  • A Microsoft 365 user account.
  • Global Administrator or Authentication Administrator role (for initial setup/management).
  • Microsoft Authenticator app installed on the primary device.
  • Secondary device (another smartphone/tablet) for the second authenticator app.
  • (Optional) FIDO2 Security Key.
  • Azure AD Premium P1/P2 license for Conditional Access (highly recommended for MSPs).
Step 1: Enable MFA (if not already enabled)

For MSPs, using Conditional Access policies is the recommended way to enable and enforce MFA. Security Defaults are a simpler option but offer less flexibility.

Method A: Using Conditional Access Policies (Recommended for MSPs)
  1. Sign in to the https://entra.microsoft.com/ Microsoft Entra admin center (formerly Azure Active Directory admin center) as a Global Administrator.
  2. Navigate to Protection > Conditional Access.
  3. Click + New policy.
  4. Name the policy: e.g., “MFA for All Users” or “MFA for Admins”.
  5. Under Assignments > Users or workload identities, select the relevant scope (e.g., All users, or specific administrative roles/groups). For MSPs, definitely target administrative roles.
  6. Under Cloud apps or actions, select All cloud apps (or specific sensitive apps).
  7. Under Conditions (optional, but highly recommended for MSPs):

    • Locations: Exclude trusted locations (e.g., your MSP office IP ranges) to reduce MFA prompts when users are on-site, but require MFA when outside.
    • Device state: Consider requiring MFA for non-compliant devices.
    • Sign-in risk: Set to require MFA for medium or high sign-in risk.
  8. Under Grant:

    • Select Grant access.
    • Check Require multi-factor authentication.
  9. Set Enable policy to On.
  10. Click Create.
Method B: Using Security Defaults (Simpler, less flexible – good for quick enforcement)

If you don’t have Azure AD Premium licenses, Security Defaults provide a baseline level of MFA enforcement.

  1. Sign in to the https://entra.microsoft.com/ Microsoft Entra admin center as at least a Security Administrator.
  2. Browse to Identity > Overview > Properties.
  3. Select Manage security defaults.
  4. Set Security defaults to Enabled.
  5. Select Save.

Note: If you previously had “per-user MFA” enabled, you must disable it before using Conditional Access or Security Defaults. You can do this from the Microsoft 365 admin center > Users > Active users > Multi-factor authentication link, and set user status to disabled.

Step 2: User Registers Their First Authenticator App (Primary)

The first time a user signs in after MFA is enabled, they will be prompted to set it up.

  1. The user navigates to https://myaccount.microsoft.com/.
  2. They sign in with their username and password.
  3. They will see a message: “Your organization needs more information to keep your account secure.” Click Next.
  4. On the “Keep your account secure” page, they will be prompted to set up the Microsoft Authenticator app (recommended).

    • Choose Mobile app from the dropdown.
    • Select Receive notifications for verification (for push notifications) or Use verification code (for TOTP codes). Push notifications are preferred for ease of use and security. Click Set up.
    • A QR code will appear on the screen.
  5. On their primary smartphone:

    • Open the Microsoft Authenticator app.
    • Tap the + sign (top right on iOS, top left on Android) and choose Work or school account.
    • Select Scan a QR code and scan the code displayed on the computer screen.
    • The account will be added to the app.
  6. On the computer, click Next. Microsoft will send a test notification to the app.
  7. On the smartphone, approve the notification (or enter the number matching code if enabled).
  8. Once verified, click Next on the computer.
  9. They may be prompted to set up an alternative verification method (e.g., phone number) as a backup. It’s recommended to do this.
  10. Click Done.
Step 3: User Registers a Second Authenticator App (or another method)

Once the primary authenticator is set up, the user can add additional methods via their security info page.

  1. The user navigates to https://myaccount.microsoft.com/ and signs in (they will be prompted for MFA using their primary method).
  2. On the left-hand navigation, click Security info.
  3. Click + Add method.
  4. From the dropdown, choose the desired method:

    • Authenticator app: To add the Microsoft Authenticator app to a second device or another TOTP authenticator (e.g., Google Authenticator, Authy).
    • Phone: To add a secondary phone number for SMS or voice calls (less secure, use with caution for admin accounts).
    • Security key: To add a FIDO2 hardware security key (highly recommended for strong phishing resistance).
  5. For a second Authenticator App:
    1. Select Authenticator app and click Add.
    2. Follow the on-screen prompts. It will present a new QR code.
    3. On the second device, open the chosen authenticator app (e.g., Microsoft Authenticator, Google Authenticator).
    4. Add a new account (Work or school account for Microsoft Authenticator, or generic TOTP for others) and scan the QR code.
    5. Complete the verification steps.
  6. For a Security Key (FIDO2):
    1. Select Security key and click Add.
    2. Follow the instructions. This will involve plugging in the FIDO2 key and touching it when prompted.
    3. Give the key a memorable name.
  7. Once successfully added, the new authentication method will appear in the “Security info” list. The user can also set a default sign-in method from this page.
Important Considerations for MSPs:
  • Dedicated Admin Accounts: For managing customer tenants, use dedicated administrative accounts for each technician rather than a single shared account, where possible. This improves auditability and accountability. When shared accounts are necessary (e.g., for legacy systems or break-glass scenarios), ensure they are tightly controlled and monitored.
  • Microsoft 365 Lighthouse: For CSP partners, Microsoft 365 Lighthouse offers a centralized portal to manage multiple customer tenants, including MFA configuration and monitoring. This can significantly streamline MSP operations.
  • Azure Lighthouse: For Azure services, Azure Lighthouse enables MSPs to manage resources across customer subscriptions from their own tenant, reducing the need for direct access to customer tenants and simplifying MFA management.
  • Privileged Identity Management (PIM): For high-privileged roles, implement PIM to provide just-in-time and just-enough access. This requires administrators to activate their elevated roles, and each activation can require MFA, even if their standard user account doesn’t.
  • Regular Reviews: Conduct quarterly or bi-annual reviews of all administrative access, including MFA configurations, for all customer tenants.

By following these best practices and understanding the configuration steps, MSPs can effectively manage multiple authenticator apps for their users, enhancing security posture across all their managed Microsoft 365 customer environments.

Getting Global Administrators using the Graph

A common task that needs to be performed is to return all the Global administrators in a tenant via PowerShell. With the focus on using the Microsoft Graph to do things like this you can use the following:

import-module Microsoft.Graph.Identity.DirectoryManagement


Connect-MgGraph -Scopes “RoleManagement.Read.Directory”,”User.Read.All”

$globalAdmins = Get-MgDirectoryRole | Where-Object { $_.displayName -eq “Global Administrator” }
$globalAdminUsers = Get-MgDirectoryRoleMember -DirectoryRoleId $globalAdmins.id

$globaladminsummary = @()
foreach ($adminuser in $globalAdminUsers) {
     $user = Get-MgUser -userId $adminuser.Id
     $globaladminSummary += [pscustomobject]@{      
         Id                = $adminuser.Id
         UserPrincipalName = $user.UserPrincipalName
         DisplayName       = $user.DisplayName
     }
}


$globaladminsummary

which I have also uploaded to my Github repo here:

https://github.com/directorcia/Office365/blob/master/graph-globaladmins-get.ps1

You may also need to consent to some permissions like:

image

If your user doesn’t have these. Permissions required are:

RoleManagement.Read.Directory
User.Read.All

The list of tenant global admins will be held in the variable $globaladminsummary at the completion of this script.

Need to Know podcast–Episode 275

Join for an episode with MVP Rory Braybrook where we learn more about modern identities, especially Azure including B2B and B2C. Identity is so critical to everything we do in IT these days it is important to have a refresher to understand what’s what and how it can be used effectively. I’ll also bring you the latest news and updates from the Microsoft cloud world so listen in and share your feedback.

This episode was recorded using Microsoft Teams and produced with Camtasia 2020.

Brought to you by www.ciaopspatron.com

Take a listen and let us know what you think – feedback@needtoknow.cloud

You can listen directly to this episode at:

https://ciaops.podbean.com/e/episode-275-rory-braybrook/

Subscribe via iTunes at:

https://itunes.apple.com/au/podcast/ciaops-need-to-know-podcasts/id406891445?mt=2

The podcast is also available on Stitcher at:

http://www.stitcher.com/podcast/ciaops/need-to-know-podcast?refid=stpr

Don’t forget to give the show a rating as well as send us any feedback or suggestions you may have for the show.

Resources

Rory Braybrook – LinkedIn, Authory

Windows 11: A new era for the PC begins today

Welcome to the new Whiteboard

Mailbox storage limits

Microsoft Ignite

How cyberattacks are changing according to new Microsoft Digital Defense Report

Microsoft Digital Defense Report

Defending Windows Server 2012 R2 and 2016

Azure AD Sign-in error code look up

image

When you are looking at various entries in the Azure AD logs you will find, under the Basic Info tab, a Sign-in error code and directly below that a Failure reason field as shown above.

image

The above, shows you these fields in more detail.

You may not be aware but if you navigate to the web site:

https://login.microsoftonline.com/error

image

and plug in the Sign-in error code from the event, you should see information like that shown above. Most of it should match what the Failure reason field says. There can however, also be additional information in there that may help you when it comes to troubleshooting these events.


Protecting your Microsoft 365 environment using Azure AD Privileged Identity Management (PIM)

If you are managing a Microsoft 365 environment my recommendation is to do so using a Microsoft 365 E5 SKU, no matter what else in in that tenant. The reason for having at least one Microsoft 365 E5 SKU in your environment is that it provides a wealth of additional features that directly benefit administrators. One of these is Azure AD Privileged Identity Management (PIM).

image

In a nutshell, PIM allows you to do just-in-time (JIT) role escalation. This means that users can be given the permissions they need to do things, only when the need them. It means that you don’t need to have users with standing global administrator access, they can be escalated only when they actually need those privileges. Standing elevated privileges is something that you should be looking to minimise or eliminate in your environment so that if an account does get compromised it won’t have access to the ‘family jewels’. PIM is also a way to potentially minimise the threat of a ‘rogue administrator’ given that it can have an approval process tied to it as well. Most important, all PIM actions are audited in detail which is always handy to have.

PIM is a feature of Azure AD P2 and as mentioned, included in Microsoft 365 E5. Best practice is to ensure you have an ‘emergency break-glass’ administration account tucked away as a backup before you start restricting existing administrators with PIM. Once you have both the license and a ‘get out of jail’ account you are ready to use PIM.

A good example to help you understand the benefits of PIM is to illustrate how I use it myself in my own production environment. The account that I use for my day to day work used to be a global administrator but best practices dictates that it really shouldn’t be. However, given the number of browser sessions I have open already I didn’t want to add yet another one to be checking administrative tenant level ‘stuff’. PIM to rescue! With PIM, my account can stay as a member account by default and I can escalate it to be a global administrator as needed.

image

One of the things I like to check is Microsoft Cloud App Security for my tenant. As you can see above, by default, I now have no privileges.

To elevate my privileges I follow this process:

Activate my Azure resource roles in Privileged Identity Management

 image

This means that I login to the Azure Portal and then navigate to Azure AD roles in PIM as shown above. Here I can see that I can activate the Global administrator role by selecting the Activate link as shown.

image

When I do this a dialog box appears and my credentials are verified. You can enable the requirement to again prompt for MFA during this validation process if you wish. That means, even if I am already logged in successfully, I need to complete an MFA challenge again to proceed.

I can now select the time required to complete my work up to a pre-defined Duration limit. Here I’m going to select the full 8 hours for a full work day at my desk. I also need to provide a Reason for elevation. This information will be recorded and held with the auditing information. This means I can track when and why I elevated.

When complete, I press the Activate button at the bottom of the page to continue.

image

The activation request is then processed according to pre-define rules. In my case, I have elected to have automatic approvals but you can refer approvals to a third party if you wish for greater protection.

image

In about 30 seconds my activation is complete and if I now look in the Active roles area of the console I see that I am indeed a global administrator.

image

If I now refresh my Microsoft Cloud App Security page, you see that I can get access as a normal administrator. This is also the same with all the other administrator areas in the tenant thanks to undergoing the elevation to a Global Administrator thanks to PIM.

The good thing is now I can work using my normal account, check and monitor what I need to without using a different account. I can also rest easy that after the 8 hour time limit my account will again be de-activated back to being a member user. Thus, at the end of the day, I simply shut down and the account will automatically be de-activated for me without me needing to remember to do it. I can of course, manually de-activate the account at any time if I wish, say if I needed to go out somewhere. It is also easy enough for me to re-activate again if I need to do any additional work.

image

What I also like is the audit logging as shown above. Having it all in one place in the PIM console makes it easy for me to verify what has been happening with the process over time.

So in summary, I am using PIM to elevate my normal work account to an escalated level as needed during the day. This means that I don’t have to maintain standing administrator access for the account but I still have the convenience of using it to perform administrator roles as needed.

To set this up for yourself, you’ll need M365 E5 or Azure AD P2 as well as a ‘break-glass’ account. Then you’ll need to configure the roles you wish to escalate to via:

Configure Azure resource role settings in PIM

You can get quite granular here if you wish, but my advice is that you keep it simple to start with and go from there. For me, I just wanted the simple process of becoming a ‘normal’ global administrator.

You can have multiple roles, with different access for different users if you wish. In my case, I’m just focusing on the role of the tenant administrator. As I said, you can also have approvals sent to a third party or parties if you want for an extra level of protection if desired. There lots of settings you can customise with PIM.

Using PIM now gives me extra level of protection when it comes to administration rights. It means my production user isn’t a global administrator by default. I can however, use that same account as a global administrator, by going through a simple automated escalation process that requires MFA for greater security. Additional benefits include that I get great auditing and tracking, I can manually de-activate those rights at any point and those rights will also be automatically de-activated for me after a specified time limit and I also get alerting.

If you want to make your Microsoft 365 environment, especially you administrator logins, more secure then I suggest you take a look at PIM. Even for a small environment like mine, it is great value.

Handy Azure AD authentication method report

image

If you go to your Azure portal and navigate to Azure Active Directory, you should see something like that shown above. If you then scroll down the options on the left and locate Usage & insights , under Monitoring as shown above, you’ll end up here.

image

Selecting Authentication method activity on the left gives you some information about things like MFA, Self Service Password reset and more. You can also select the Usage tab at the top of the window on the right, will give you some nice historical graphs well.

An easy way to see how and when people are completing security registrations for Azure AD.