Microsoft Entra ID has a huge amount of configuration. Unfortunately, the default configuration for new tenants is not optimal from a security perspective. And many organizations don’t change the default configuration, or change it only slightly, but don’t apply all the optimal settings from a security perspective.

I routinely see settings in customer tenants that are very risky and could be a source for a future security incident.

Let’s take a look at the most important settings. The following article is not “one size fits all” and thus may not be suitable for all tenants. Neither is it a complete tenant security solution, but always needs to be configured individually according to the needs and expectations of a particular organization.

Password Reset

Self-Service Password Reset (SSPR) is a very practical and useful thing. It allows users to easily reset their password if they cannot log in or their account has been locked. And they don’t have to contact the corporate helpdesk right away for such a small thing. It can also be easily integrated directly into the Windows 10/11 login screen.

But just as users can reset their password, so can an attacker. And in incident response, we commonly see that an attacker tries or has tried to reset some users’ passwords via self-service password reset.

So consider whether a self-service password reset is really desirable. And if so, require methods that are secure enough and always require 2 different authentication methods. The security question is usually not secure enough, and alternative (personal) email is definitely not secure.

Alternatively, limit self-service password resets to only select groups of users.

Password Reset Notifications

It is also advisable to activate notifications sent to users when their password is reset. And it is very important to activate notifications to all admins if another admin resets his/her password. This is because if it is an unwanted password reset, it can be a major security issue. Therefore, all admins should receive a notification.

User Settings

Here comes the big problem with the default configuration, which from my point of view is all very risky.

Default User Role Permissions

Users should not be able to register applications. Registering applications is potentially very risky and can do a lot of damage. And regular users typically have no reason why they should register Microsoft Entra ID apps. Only admins should do that.

Ordinary users should also not be allowed to create tenants. Again, this is a matter that should be in the hands of admins.

It’s the same with security groups. There is usually no reason why users should be able create security groups. Regular users can create Microsoft 365 groups and that should be sufficient for their needs.

Guest User Access

Guests should not have the same rights as internal users. Internal users have been trained, have signed contracts, have company devices, … Guests usually don’t have any of that and maybe they just need to download a file from SharePoint Online. So I recommend limiting guest rights to only their own objects.

Administration Center

By default, users can open the Microsoft Entra ID admin portal. This is of course read-only for them and they can’t see many things at all. But again, from my point of view, there is no reason why a normal user should have access there at all.

Show keep user signed in

And lastly, I’d like to mention “Keep me signed in” (KMSI) here. I recommend disabling this. Nothing will happen on corporate devices, nothing will change. Single Sign-On (SSO) will work there and the user will not encounter any login screen at all.

Keep me signed in is therefore a matter of primarily unmanaged devices or browsers. And there, in my opinion, it is desirable that the permanent login option is not available.

This is because KMSI creates a so-called persistent cookie that remains active even after the browser is closed. If KMSI is not checked, after closing the browser and reopening it, it is necessary to log in again, which in my opinion is desirable on unmanaged devices.

External Collaboration Settings

Cross-tenant access settings is fine by default. In general, I do not recommend trusting foreign MFA, trusting foreign compliant devices, or foreign hybrid joined devices. I recommend enabling this trust only for specific organizations that you trust and with whom you regularly work, for example.

What I recommend changing is the Guest Invite Settings. By default, anyone can invite guests. Even guests themselves can invite other guests. That doesn’t seem appropriate to me. At a minimum, I recommend setting that only internal users can invite guests. Optimally, only administrators should invite guests, but this is often not feasible. So option number two is the most common one.

If it is possible, you can restrict guest invitations sent only to selected domains.

Delegated Admin Partners

Be very careful who you have in Delegated Admin Partners. If you are purchasing licenses or services from a Microsoft partner, you will most likely have some partner organizations there. There may be even more than one.

Delegated Admin Privileges (DAP)

The old partner management model always automatically assigned Global Admin permissions, the highest possible permissions, to a given partner. These permissions were assigned to the entire partner organization, and it was purely up to the partner to decide who to factually assign those rights to. Therefore, it could easily happen that all employees of a given partner would have Global Admin rights in your tenant. That is a huge security risk.

Granular Delegated Admin Privileged (GDAP)

Newly used is the so-called GDAP – Granular Delegated Admin Privileges. Partners no longer necessarily have Global Admin permissions, but for example only a license admin permissions if they take care of your licenses. But it is still the case that it is assigned to the whole organization, i.e. any user from the partner organization.

It’s important to review these permissions and limit them to the minimum necessary. The partner organization in question may be trusted and, at first glance, there may not be a problem. However, supply chain attacks are very common, where an attacker successfully attacks even a regular user account at a given partner organization. However, if the given regular user account at the partner has privileges in your tenant, the attacker automatically gains access to your tenant as well.

Enterprise Applications

Enterprise applications are used to integrate external tools or services with Microsoft Entra ID. More details and comparison in my article Difference between Entra ID Enterprise Apps and App Registrations.

Here, I would recommend reviewing all registered Enterprise Apps and deactivate and then delete the ones you don’t know what they are for. There will very likely be many apps registered there that were registered by regular users in the past, as this is enabled by default.

The essential settings are in the Consent and Permissions section. Here you control who can grant consent to apps, i.e. register new enterprise applications, and under what conditions. By default, anyone can do this, which is very risky.

I recommend changing the setting to Do not allow user consent and right below that Do not allow group owner consent.

Optionally, you can allow users to ask the administrator to approve the application. This is usually a good solution. If a user wants to use an external application or service that is not yet registered with the tenant, they can ask the administrator for approval. The administrator will then be notified by email and can decide whether the application is desirable or not.

In large organizations, however, the registration of enterprise applications is usually purely the responsibility of corporate IT and end users do not even have the possibility to request approval.

Conditional Access Policies

Conditional access policies are such a large topic that I have described them in a separate article Recommended Conditional Access Policies in Microsoft Entra ID.

Named Locations

Named Locations allow you to define locations that are then used in conditional access policies. Organizations typically define here the IP ranges used in their offices, and possibly their server IP ranges as well.

You can mark those IP ranges that the organization has full control over as trusted locations. Again, this is a property that can be used in conditional access policies. In addition, this information is also taken into account in Identity Protection.

Defining named locations is also useful because named location information is also stored in the sign-in log. This makes it easier to navigate when tracking something down, as you can see what location it is right in the log.

In general, I recommend setting named location for each type of your physical location. For example, each branch separately, each datacenter separately, etc. This will allow for better granularity both when defining conditional access policies and when searching sign-in logs.

If you also use IPv6, be sure to define IPv6 ranges for named locations as well. Microsoft Entra ID runs on IPv4 + IPv6, so users with IPv6 connectivity will likely primarily access it via IPv6.

Countries location

Named locations can also be used to define countries. The geolocation information primarily uses geo-ip database. This may not always be accurate and for some IP addresses this information may not be available at all.

The other option is to use GPS information from the user’s phone if the Microsoft Authenticator application is used for authentication.

This information can also be used, for example, to block logins from certain countries or, on the other hand, to allow logins from certain countries only. This can reduce the risk of attacks to some extent.

Authentication Methods Policies

My first recommendation would be to migrate your MFA authentication policies to the modern management mode of these policies. This requires disabling all settings in Password Reset and the old MFA portal. This gives you significantly more control over who can use which login methods in which situations. Or, better yet, what login methods will be required in different situations.

Of the available methods, FIDO2 and Certificate-based authentication are the most secure, as both methods are considered phishing-resistant. Both methods allow for additional configuration, so for example with FIDO2 you can require attestation or you can allow only selected key types.

In addition, you can configure individual methods to include or exclude user groups to scope the deployment.

Password Protection

Password Protection is enabled for cloud accounts automatically for all license types. If you have at least Microsoft Entra ID Premium P1, you can also integrate the service with onpremises Active Directory and further configure it.

I recommend setting up a custom list of blocked words that correspond to your organization, country or city. Such words that a user would typically use in their password. Usually these are the name of the organization in various forms, names of favorite sports teams in the city or state etc.

Registration Campaign

MFA registration campaign allows you to actively encourage users to register multi-factor authentication methods. I definitely recommend activating the campaign. It is advisable to allow users some time to register so that it does not force them to register MFA methods at the beginning of an important meeting, for example – 7 days should be sufficient.

Authentication Strengths

Authentication strengths are used to define authentication requirements that can then be used in conditional access policies.

By default, there are three predefined. One for passwordless authentication, one for phishing-resistant authentication, and one that allows all types of authentication.

Additional custom ones can be created. It is a good idea to think about what types of users you have in your organization and what authentication requirements you will require in what situations.

A normal user login is unlikely to have as strict requirements as, for example, a global administrator login. This is where the huge advantage of granularity comes in, because each conditional access policy may require a different type of authentication. Thus, different situations and scenarios may be covered by different authentication requirements.

For highly privileged accounts, I recommend requiring a phishing-resistant MFA for each login. These are the most sensitive accounts, so they should be protected as best as possible.

For other privileged accounts, a passwordless MFA might be sufficient.

And for regular users, I recommend creating a custom authentication strength where you enable all phishing-resistant methods, passwordless MFA, and optionally add Temporary Access Pass (forgotten phone or first-time login of new employees, for example) and push notifications in Microsoft Authenticator.

Authentication Methods Settings

The last part of the security settings allows you to allow users to report suspicious login activity a enforce the strongest authentication method for MFA.

Report Suspicious Activity

These are activities where the user receives a request for multi-factor authentication on their phone without triggering any login activity.

These reported events will automatically change the user’s risk to High Risk, as they have likely compromised credentials. This can then be responded to by an administrator manually or automatically by a user risk policy within Identity Protection.

System-preferred Multifactor Authentication

The second setting is for System-preferred multifactor authnetication. Users can have multiple MFA methods registered, such as mobile phone and Microsoft Authenticator application. If they have multiple methods, one is always the default. The default method is the one that is invoked automatically when the user logs in.

So, if a user has registered Microsoft Authenticator app and mobile phone number and has SMS code authentication as the default setting, after entering the username and password, the user will automatically receive an authentication SMS. The user then has the option to manually switch MFA to any other registered method if needed, in this case for example a phone call to the specified phone number or a push notification to the Microsoft Authenticator app.

System-preferred multifactor authentication works the way that it automatically selects the most secure MFA method that the user has registered. So, in the example above, push notifications to Microsoft Authenticator would automatically be used as the default method since this method is more secure than authentication via SMS or phone call.

Diagnostic Settings

Microsoft Entra ID generates a lot of important information in the form of logs. These logs are available from the Microsoft Entra ID web interface, but only for a limited time depending on the license type. In addition, the web interface does not allow efficient work with logs, searching, filtering, correlation, etc.

For the above reasons, it is very important to collect and archive the logs in some log collection and analysis system (preferrably SIEM). It is easiest to use Microsoft Sentinel because integration with Microsoft Sentinel is trivial and Sentinel provides full SIEM and SOAR functionality.

Log collection is configured via Diagnostic Settings. Here you select what types of logs you want to store and where you want to store them. You can have multiple settings and send logs to multiple systems.

Final words

The above recommendations are the most common problems I see in real customer tenants. As I mentioned in the introduction, the goal of this article is not to cover the complete Microsoft Entra ID setup. Nor is the goal to provide a final configuration for all tenants of the world.

The goal of this article is to show the most common weaknesses that I encounter in practice, and perhaps provide ideas for you to think about changing the configuration in your organization as well.

If you feel I’ve forgotten something or not stated it accurately, let me know. If there is anything you would like to clarify or advise on a particular problem and scenario for your organization, please feel free to contact me via the contact page.