Top Five Security Topics For Microsoft 365 Projects

Whenever we start working on a Microsoft 365 project, after the basic setup we always encounter security-related topics or questions that lead to very long discussions. Based on recent projects, I summarized some key questions we received and how we addressed them. Hopefully, you’ll find this information useful when you prepare to deliver future projects.

For tenants already deployed with Microsoft 365, it’s a good time to revisit these points to ensure that you take advantage of the updates and enhanced features rolled out by Microsoft from time to time.

#1 Secure Defaults or Custom Configurations

Secure Defaults is a set of Entra ID recommended policies enforced on your Microsoft 365 tenant. This option is on by default for tenants created after 22 October 2019. In summary, it enforces the following policies:

1. Enables multi-factor authentication (MFA) for all users.
2. Force administrators to authenticate every time they access the Microsoft 365 admin consoles.
3. Disable basic authentication which means some client connection protocol (POP3, IMAP, ActiveSync, etc) cannot be used unless the client support modern authentication

You can refer to Microsoft’s documentation for the exact details of the settings enforced.

But should Secure Defaults be used? To me, the answer is simple:

• If you work with a tenant that doesn’t have Entra ID Premium P1 or P2 licenses, I recommend to Secure Defaults to avoid the hassle of manually configuring all the policies mentioned above individually.
• If a tenant has Entra ID Premium P1 or P2 licenses, they are likely to have specific requirements that Secure Default cannot address, like the requirement to enable the use of basic authentication for specific client protocol or only enable MFA when users access from an outside corporate network. I recommend using Conditional Access policies instead of Secure Defaults to gain more control over different connections. For example, you can implement blocking basic authentication only for specific locations by referring to this article.

#2 Methods to Enforce MFA Authentication

In my part of the world (Asia), clients often have to deal with challenges like Google Services not being available in China which has caused Microsoft Authenticator to fail to work properly in Android. To avoid confusion, we must update the authentication policy so that specific groups of users can use Microsoft Authenticator. To do that, we will have to configure the Authentication policy so that the Microsoft Authenticator app is only available to a security group as shown in Figure 1. In most clients, we will deploy specific group access to things like SMS or Telephone to address different concerns, like employee privacy.

To target an authentication method, you must create a security group (cloud-based or synced from on-premises AD) and change the target from All users to that group. Although I do not recommend disabling any of those methods, you can do so here if necessary. But remember if you want to use passwordless login or Number Matching for login, you have to make sure the user can use Microsoft Authenticator.

In addition, make sure the mobile number property in Entra ID user accounts are populated with mobile numbers in E.164 format (i.e. +<country code><phone number>, e.g. +852-12345678). We had a case recently in which the client said they populated the mobile numbers, but users did not receive any SMS. Later we found out they put the number in local format, which does not work with Microsoft’s backend for sending MFA challenge tokens via SMS.

Finally, I always encourage administrators to direct users to use the Microsoft alias link: http://aka.ms/mfasetup, instead of using other methods for MFA setup. Using the Microsoft link avoids problems if Microsoft changes how the MFA setup works. Microsoft also ensures the link redirects to the correct page if they update the sign-in experience.

#3 How to Set or Change Passwords

It is my strong belief that a passwordless approach should be used for every Microsoft 365 tenant. Going passwordless would remove many password-related issues. Nonetheless, passwords still exist and are used by various systems. As a result, we still need to take care of the password. It is important that we enforce the password expiry to ensure passwords are updated once in a while and ensure the password is secure by enforcing complexity requirements. At the moment, you cannot change the complexity requirements for passwords, only the expiry requirements (figure 2).

If you synchronize the account password hash from on-premises AD, make sure the expiry date aligns with the AD setting. Otherwise, it will create situations where the user is asked to update their password twice: once in AD, and once in Microsoft 365, thus causing more issues in the synchronization process

#4 Ensure Only Selected Users can Create Teams

This question comes up on almost all Microsoft 365 adoption projects, regardless of whether it is a new deployment or reviewing an active tenant. On one occasion, I did an assessment of a client’s tenant which has around 350+ users and 200 teams. Many of those teams were not created by IT, nor were the IT aware that the teams existed. This creates an issue not just in terms of manageability, but also in terms of security.

Because no one knows why some teams exist, clients were worried sensitive info could potentially be leaked. I am aware they can fix it by implementing DLP or Sensitivity Labels, but that’s another story. They also discovered that many of those Teams do not have owners or have a clear relationship with any business unit/team/project, making it difficult for IT to know what to do with them after discovering those Teams. That also consumes the expensive SharePoint Online storage if they are not related to any business activities. The documents ended up being archived and put away so they would not be found.

It is important to always encourage clients to put some control in place before they roll out Teams to everyone. There are some products, Powell Teams, and AvePoint, that can help with Teams Governance, or you can use PowerAutomate to approve teams before they are set up. But for that to work we need to do one key thing: take away the ability for every user to create a Team from the Teams client. We must use a PowerShell cmdlet since there is no web interface. All you need to do is create a security group in Entra ID that includes users with the right to create Teams. Then, run the script as per the instructions here. After that, restart the Teams client and users not in that group cannot see the “Create Teams” button in the Teams client. This setting applies to the web, mobile, macOS, and Windows Teams clients.

#5 What is Secure Score and Does it Help to Secure a Tenant

Secure Score is a measurement of Microsoft 365 tenant security posture created by Microsoft. The Secure Score is computed based on a task list created by Microsoft. A tenant’s Secure Score is determined by combining the scores of each completed task on the list. The list of tasks covers four key areas at the time of writing: Identity, Device, App, and Data. They are all related to different products in Microsoft 365, for example, Microsoft Information Protection is related to Data. At the end of the day, Secure Score is a way for Microsoft to show you how much more you can achieve in terms of security. It is also a way to encourage you to buy more products. But as administrators, we can leverage the list to identify some settings we may miss or overlook. We can use Secure Score as a benchmark for the tenant’s security posture, as it is evaluated periodically. In some cases, I also use it during a project to see if I have missed any security settings.

I do not intend to walk through the details of each item as it is measured here. You can access the full details about Security Score here. What I want to focus on today is leveraging Secure Score to regularly evaluate a tenant. This will generate a task list to follow up to ensure the tenant is secure.

First things first, you need to access the Secure Score portal. Here you can see your current score and a breakdown of how the secure is computed (Figure 3).

As a result of the action list generated, you can come up with a plan for increasing the security of your tenants. The action often includes recommendations from Microsoft or reference information on how to implement the items (Figure 4).

The best part of the Secure Score is that it keeps a history of previous scores and can be used as a KPI for a tenant. I ask management to review the score periodically to see how secure their tenants are. Make sure you pay attention to the action list generated by Microsoft since some require additional licenses. Focus on what you can do with the existing licenses. If the actions are really something you want to implement, Microsoft will be more than happy to help you purchase the additional license required.

Security is an Important Topic for Microsoft 365 Deployment

I believe security is not a one-time thing. We must improve configurations as the product evolves or the situation changes. Microsoft 365 provides us with many tools to secure tenants. Leverage the tips mentioned in this article and review your Secure Score to check for any updated or missing security items in your tenant.