Authentication in Microsoft Entra ID: IAM Series Part 2

In Part 1 of the IAM Series, we explored how authentication works, why it’s important from a security standpoint, and its various methods. Understanding these methods is important, but what is just as important is actually implementing them. Luckily, if the organization uses the cloud (which an increasing number of organizations are doing), they can use the cloud’s identity and access management services to secure their environments. In particular, if the organization uses Microsoft as its cloud of choice, they can use the identity and access management system known as Microsoft Entra ID (formerly Azure Active Directory).

Remember that GRC professionals are not the ones who configure these tools, so how to configure them is outside of the scope of this blog. However, they should understand the features that exist so they can recommend organizations using Microsoft adopt them. In this blog post we will go over the authentication features of Microsoft Entra ID. It might be helpful to read Part 1 first to get an overview of authentication concepts.

Overview of Microsoft Entra ID

Microsoft Entra ID is Microsoft’s cloud-based identity and access management system. It enables authentication to services like Microsoft 365, Azure, and thousands of other third-party applications. Some of what it offers include:

Authentication options (Password, Passwordless, MFA)
Authentication Strengths
Temporary Access Pass
Conditional Access Policies – used to enforce real-time access decisions based on signals
Risk-Based Authentication
Blocking of Legacy Authentication

These features allow organizations to enforce strong authentication, reduce identity-related risk, and meet compliance requirements.

Note that in addition to managing identities for cloud resources, Microsoft Entra ID can also integrate with the on-premises Active Directory through Microsoft Entra Connect.

Password-Based Authentication Features

Microsoft Entra ID offers the following password features for security:

Smart Lockout (prevent attackers from guessing passwords by locking accounts after repeated failed attempts)
Self-service password reset (allows users to reset their password without having to call the IT help desk)
Microsoft banned password list (private list of passwords that Microsoft bans the use of; this is enabled by default and cannot be opted out)
Custom banned password list (list of passwords that the organization bans the use of)

Banned password lists prevent users from choosing weak passwords, reducing the likelihood of compromise. Entra ID focuses on password length and banned password lists instead of complexity rules, which are aligned with the latest NIST password guidelines.

As GRC professionals, we should make sure all of these features, such as custom banned password lists and self-service password reset are implemented.

Multifactor Authentication Features

Passwords by themselves are not very secure. Luckily, Microsoft Entra ID provides a variety of MFA features such as:

Microsoft Authenticator App
Security Key (physical device providing phishing-resistant authentication)
SMS (easy to use but vulnerable to SIM swapping)
Voice (convenient but vulnerable to social engineering)

SMS and Voice are less secure than other second factors, while the Microsoft Authenticator App (with number matching or passwordless authentication) and Security Key are much better options. Note that Microsoft also offers an option to register users to MFA and SSPR simultaneously using Combined Registration, which is important as it reduces help desk tickets. GRC professionals need to make sure these MFA features are enabled and ensure that at least privileged accounts are using phishing-resistant methods. If MFA is not adopted, the organization is vulnerable to getting hacked due to credential theft.

Passwordless Authentication Features

Finally, Microsoft Entra ID offers passwordless authentication, which ditches passwords entirely. These methods are phishing-resistant because they rely on cryptographic keys tied to a specific device. When it comes to passwordless, Microsoft Entra ID offers:

Windows Hello for Business
FIDO2 security keys
Authenticator app passwordless sign‑in

GRC professionals should encourage organizations to adopt passwordless if they haven’t already, especially for privileged accounts. It is much more secure than other methods. They should also ensure that the organization adopts at least one of MFA or passwordless, as without it, an attacker needs to just steal someone’s password to gain access to a system. Finally, they should review reports to confirm that passwordless adoption is progressing and that privileged accounts use strong authentication, either passwordless or phishing-resistant MFA.

Temporary Access Pass

Entra ID also offers the option of a Temporary Access Pass. These are one-time tokens that can be used for:

Onboarding new employees
Recovering from lost devices
Enabling passwordless setup

Note that TAP should only be used in a small of circumstances. It is not a way to replace MFA or passwordless authentication and should never be used as a standing authentication method.

GRC professionals should recommend an organization adopt these because it reduces help desk processes, which saves time and is more secure, can be tracked, and supports zero-trust onboarding. They should verify that TAP usage is heavily restricted and monitored. If TAP usage is not monitored, an attacker could exploit it to bypass normal authentication methods like MFA and passwordless. For instance, if an attacker compromises an admin account that can issue TAPs, they can create a TAP for themselves to bypass MFA entirely.

Conditional Access

Conditional Access is the heart of Entra ID authentication governance. It is a policy engine that enforces real-time access decisions using if-then statements. For instance, if a user attempts to login in an unknown location, then an action, such as requiring multi-factor authentication (MFA) or blocking access, is enforced. Think of Conditional Access like a security guard checking ID and behavior of a person before letting someone into a restricted area.

It can evaluate signals such as:

user risk (leaked credentials) and sign-in risk (detecting suspicious or anomalous login behavior)
device compliance (does the device meet policies) and device platform (type of device)
location (where the login attempt is coming from)
client app
app sensitivity (the classification of the application being accessed)
session risk (detecting unusual session behavior)

Conditional Access is essential for GRC professionals because it enforces policy decisions consistently and provides auditable evidence of how access risks are managed. They should ensure that Conditional Access policies exist, are documented, and reviewed regularly. They also need to make sure that any exceptions to conditional access are tracked and approved only in a rare number of cases. These exceptions should havedocumented business justification, defined expiration dates, and periodic review.

Here are some examples of conditional access policies:

requiring MFA for all users
blocking legacy authentication
requiring devices to be on a certain list to access a sensitive app
requiring passwordless for privileged accounts

Organizations can also utilize Authentication Strengths, which can be used to enforce specific authentication methods such as requiring passwordless authentication for privileged accounts. Also, note that many small organizations rely on Security Defaults instead of Conditional Access. Security Defaults are Microsoft’s baseline security settings that enforce MFA and block legacy authentication for organizations that don’t use Conditional Access and are intended for intended for organizations who don’t need custom Conditional Access policies.

Finally, note that organizations should test Conditional Access policies before enforcing them to prevent the possibility of accidentally locking out users or administrators.

Risk-Based Authentication

Microsoft Entra ID uses risk-based authentication to determine the risk level of each login attempt. Risk signals come from Microsoft threat intelligence sources such as Microsoft Defender for Identity and impossible travel detection (such as signing in from two distant countries within minutes). There are two types of risk that are evaluated: user risk (checking for leaked credentials) and sign-in risk (checking for suspicious login behavior). This integrates with conditional access to determine what action should be taken based on the level of the risk.

Risk-based authentication has many benefits from a security standpoint, such as continuous monitoring, automated risk response, and the ability to detect compromised accounts quickly. It is important for GRC professionals because it provides auditable evidence of how the organization responds to suspicious activity and reduces the likelihood of credential‑based breaches.

Legacy Authentication

As mentioned in the last blog post, legacy authentication is an authentication method that should not be used because some legacy protocols transmit credentials insecurely and they bypass MFA. Microsoft Entra ID offers ways to block legacy authentication, and is recommended by Microsoft to be blocked by default, which can be done through Conditional Access or Security Defaults. Legacy authentication is dangerous for the following reasons:

No MFA support
Credentials are sometimes sent in plaintext
Common attack vector for credential stuffing

GRC professionals should ensure organizations have legacy authentication completely disabled for two reasons: blocking it is a common auditing requirement and legacy authentication bypasses MFA, which as mentioned before is a must-have for many organizations. If it remains enabled, attackers can bypass MFA entirely.

Reporting and Monitoring

Authentication in Microsoft Entra ID isn’t just about enabling features. It’s also about visibility. The cybersecurity team can view logs and reports such as:

Sign‑in logs to detect suspicious activity, accessible through Monitoring & Health
Audit logs to track changes, accessible through Monitoring & Health
Authentication methods reports to track what authentication methods were adopted, accessible through Monitoring & Health
Risk reports to identify compromised accounts, accessible through Entra ID Protection
Conditional Access Insights to identify how those policies are applied and whether they are working properly

From a GRC perspective, these logs provide the evidence needed to verify control effectiveness. Auditors often review sign‑in logs to verify MFA enforcement and other Conditional Access policies are working as intended.

GRC professionals should review these logs regularly, ensure that log retention policies meet compliance requirements, and use these logs during audits and investigations. They should also recommend that these logs are exported to either a SIEM or an MSSP, depending on which one the organization uses, if it hasn’t been done already. This is because Entra ID logs only have 30-day retention and compliance frameworks require longer retention periods.

In addition, GRC professionals should recommend that the organization periodically reviews their access policies, document and tightly control break-glass accounts to prevent misuse, and document exceptions and approvals to the standard authentication procedure to make it unlikely an attacker can use one of those accounts to get into a system.

Conclusion

This post covered how authentication is implemented in Microsoft Entra ID, which provides strong, modern authentication capabilities that organizations should take advantage of. This is critical as authentication is an important part of identity and access management.

Even though GRC professionals may not be the ones who configure these Entra ID authentication tools, they should understand them well enough to recommend their adoption and verify that the right controls are in place. Strong authentication controls directly support compliance and risk reduction. In particular, auditors will commonly request Conditional Access policy reports, MFA adoption reports, sign‑in logs, and Legacy Authentication block reports. Authentication is used in a variety of industry frameworks such as ISO 27001 (A.5.17, A.8.2, A.8.3.), SOC 2 (CC6.x) and NIST CSF (PR.AC, DE.AE), which require organizations to enforce strong authentication, monitor access, and prevent unauthorized use of credentials..

Despite how important authentication is to identity and access management, it is only one part of IAM. Once someone gets access to a system, they should not be allowed to do everything (such as alter financial records, especially if their job does not require that). They should only be allowed to do what is required for their job. Similarly, admins should not have access to admin resources when they are not performing administrative tasks (this can be managed using Privileged Identity Management). Configuring these controls is known as authorization and will be covered in the next blog post in this series.