A
Alex Weinert
We’ve written a lot about how attackers try to break passwords. The solution to password attacks—still the most common attack vector for compromising identities—is to turn on multifactor authentication (MFA).
But as more customers do the right thing with MFA, actors are going beyond password-only attacks. So, we’re going to publish a series of articles on how to defeat more advanced attacks, starting with token theft. In this article, we’ll start with some basics on how tokens work, describe a token theft attack, and then explain what you can do to prevent and mitigate token theft now.
Before we get too deep into the token theft conversation, let’s quickly review the mechanics of tokens.
A token is an authentication artifact that grants you access to resources. You get a token by signing into an identity provider (IDP), such as Microsoft Entra ID, using a set of credentials. The IDP responds to a successful sign-in by issuing a token that describes who you are and what you have permission to do. When you want to access an application or service (we’ll just say app from here), you get permission to talk to that resource by presenting a token that’s correctly signed by an issuer it trusts. The software on the client device you’re using takes care of all token handling behind the scenes.
Figure 1: Basic token flow
The first token you get, called a session token, shows that you successfully signed into the IDP, and how you signed in. When you sign into an app, it can exchange that session token for an access token, which gives you access to a specific resource for a certain amount of time without having to reauthenticate. To use an analogy, think of an amusement park. The IDP is the ticket office, which issues a park pass that provides credits for different rides. If you want to go on the roller coaster, you go to the ticket office, show your season park pass, and receive a ticket for that ride.
Just as you might be able to buy a day pass, season pass, or lifetime pass to the park, each token has a lifetime, usually between and 24 hours. And just as a 12-month season pass may get you a one-day pass to a specific ride, session tokens can have different—and usually much longer—lifetimes than access tokens. Moreover, access token lifetimes can differ, so the roller coaster pass may last an hour while the Ferris wheel pass is good for an entire day.
Traditionally, longer lifetimes are more convenient for users and more resilient against potential IDP outages (they save round trips to the IDP and associated latency) but riskier, while shorter lifetimes are safer (the IDP checks the integrity of the request more often). Technologies such as continuous access evaluation provide continuous assessment, so a shorter token lifetime isn’t a benefit when these are in place. When a token expires or continuous access evaluation reports heightened risk, the client goes back to the IDP and requests a refresh. This process is typically invisible to users, but if a risk condition has changed, and your organization policy requires it, then you may have to reauthenticate and get a new token. One last thing to note: while it’s a bummer to lose your roller coaster ticket, it’s really bad to lose your season park pass. An attacker can use your roller coaster ticket to get on a single ride for a short while, but with your season park pass, they can get on any ride for as long as they want. It’s similar with which, if stolen, give an actor a lasting ability to get access tokens.
Attackers steal tokens so they can impersonate you and access your data for as long as that stolen token lives. To do this, they get access to where a token is stored (on the client, in proxy servers, or in some cases in application or network logs) to acquire it and replay it from somewhere else.
Figure 2: Token theft cyberattack
When an attacker steals your session token, it’s like picking your pocket after you’ve purchased your all-access season park pass at the fair’s ticket office. Because a token is digital, token theft is like stealing the pass from your pocket, making a photocopy, and then putting the original back in your pocket. The attacker can use their copy of your session token to get unlimited new access tokens to keep stealing your data, just as they can show a copy of a valid park pass to keep getting on rides without paying.
An attacker stealing your access token is comparable to someone and stealing your ride ticket as you stand in line. They do the same copy-and-replace trick, using their copy of your token to access the resource, just as they could show a copy of a valid ticket to get on an individual ride without paying.
And because in both cases the attacker puts the original pass or ticket back in your pocket, you don’t even know an attacker is riding the rides in your name. Your token seems fine, even though an attacker is using an illegitimate copy of it, and it may take a while to determine that anything is amiss—if you ever do.
Here’s an example:
Contoso stores all their documents in a secure cloud storage service and requires all employees to verify their identity using MFA before accessing it.
One day, after starting their workday by signing into Contoso's cloud storage service, a user inadvertently installed malware on their device by clicking on a malicious 'phishing' link sent to them via email. The malicious code copied the user's session token and sent it to the attacker.
The attacker then used the stolen and MFA-validated session token, now copied to their machine, to gain access to Contoso's environment.
The attacker then downloaded as many documents as they could access, including a bunch of confidential reports, and leaked them on the internet.
Use of malware on the client to acquire the token is one common, easy method for attackers. Other tactics used to steal tokens include:
While token theft still constitutes fewer than 5% of all identity compromises, incidents are growing. alone, we detected 147,000 token replay attacks, a 111% increase year-over-year.
IDPs and clients should handle tokens as securely as possible by only transmitting them over encrypted channels and not storing them in the open. But if an attacker infiltrates the device or network channel as in the example above, they can steal tokens and use them until they expire.
Ideally, a token would only work when used from the device to which it was issued. That is, if replayed from a different device, such as one an attacker controls, the would be rejected.
A key part of Microsoft’s protections against token theft is the use of tokens that are cryptographically tied to the device they . This is often called token binding, but may also be called sender constrained tokens, or token proof of possession. Token protection makes it harder to execute the main types of attacks designed to steal tokens, including network-based attacks and those using malware on the device by restricting use of the stolen token from devices they weren't issued to.
In Microsoft Entra, token protection binds tokens to cryptographic keys specific to the device and ties them to the device registration. Once developers enable their applications to use protected tokens, you can enforce an Entra Conditional Access policy that requires client applications to use protected tokens to access a service. This policy rejects tokens which are not cryptographically tied to the device they were issued to. In the theme park analogy, this is like the ticket office taking your picture and printing it on your ride ticket and requiring ride operators to match the picture to your face before letting you ride.
Figure 3: Token protection in Microsoft Entra
This is a large project, spanning operating system platforms, native and web applications, all our cloud services, and the full range of different tokens in use for each case. It will be released in stages for specific scenarios. The first stage, in public preview now, protects the sign-in session tokens that native applications on Windows devices use when accessing Exchange, SharePoint and Teams services.
Token protection policy is available for Windows clients today. We’ll support Azure management scenarios and web applications that access Microsoft 365 resources and extend our cross-platform capabilities to Mac, iOS, Android, and other clients over the next year.
Token protection will offer the strongest protection against token theft; however, it will take the industry time to update all applications to use bound tokens. The good news is that Microsoft offers compelling countermeasures against attacks involving token theft that you can use today to reduce their risk and impact. We recommend a systematic defense-in-depth approach:
The first line of defense is to reduce the chances of attackers stealing tokens in the first place, and below are some well-established techniques for building it. It’s the equivalent of keeping your ride tickets and park passes safe from pickpockets while you’re in the theme park.
Require managed and compliant devices. Use device management and define Conditional Access policies to require that users access resources from a compliant device. Compliance policies we recommend to reduce the risk of successful token theft from devices include:
Find step-by-step instructions for enabling credential guard in our documentation.
Turn on Credential Guard for your Windows users. If your users are running Windows 10 or later, you can prevent theft of Active Directory credentials by configuring Credential Guard, which us es virtualization-based security (VBS) to isolate local and cached credentials so that only privileged system software—and not malware—can access them. Starting in Windows 11, version 22H2, Credential Guard is on by default for devices that meet requirements. This also helps protect cloud applications and resources when hybrid-joined devices using Active Directory authentication initiate a session to access cloud applications.
Find step-by-step instructions for enabling credential guard in our documentation.
While device management and strong credentials certainly reduce the risk of token theft, not everyone has them, and they’re still not completely foolproof. The next layer of defense is to prevent attackers from using stolen tokens for ongoing access by configuring policies to reject them wherever possible, and by detecting attempted use and responding automatically.
Require token protection in Conditional Access, and where possible, choose apps and services that use token protection. Microsoft is updating our apps, identity provider, and operating systems to support token protection, so if you’re using our apps and platforms, be sure to use the latest versions. Then configure Conditional Access to require token protection for sign-in sessions so only applications and devices using bound sign in session tokens, which can’t be used if they’ve been stolen and moved to another device.
Find step-by-step instructions for creating a Conditional Access policy that requires token binding in our documentation.
Create a risk policy to disrupt token theft in your environment automatically. When a user initiates a session or attempts to access an application, ID Protection will examine user and session risk factors to see if any have changed. Configure Conditional Access policies to protect both medium and high-risk sessions by either challenging users with MFA or by requiring reauthentication. This will make it difficult or impossible for an attacker to initiate a session using a stolen session token.
Wherever available, Continuous Access Evaluation (CAE) can automatically invalidate tokens when ID Protection raises the risk for a user or a service principal. This triggers the risk-based Conditional Access policies to mitigate in real-time, requiring re-authentication.
Find step-by-step instructions for creating risk-based Conditional Access policies in our documentation.
Reduce the risk of token reuse by restricting sessions for use within network boundaries. Most attackers use stolen tokens from untrusted IP addresses. You can establish network boundaries with policies that prevent users from accessing your resources if they’re coming from unknown locations or from known bad locations.
Restrict networks with Entra Conditional Access: Conditional Access includes controls that will block requests from outside a network compliance boundary that you define. This will prevent an attacker from refreshing a stolen Entra token, restricting its use to the lifetime of the token.
Find step-by-step instructions for defining a network compliance boundary with Conditional Access in our documentation.
Enhance network controls with Microsoft’s Security Service Edge (SSE) solution: To prevent the attacker from using a token outside of a trusted network at all, Entra Internet Access and Entra Private access use agents installed on endpoints and a compliant network check (enforced in real-time via CAE) to verify whether a user is connecting from a trusted network. Find step-by-step instructions for enabling compliant network check with Conditional Access in our documentation.
CAE-capable applications and services such as Teams, Exchange Online, and SharePoint Online will continuously enforce the IP-based named location Conditional Access policies and compliant network policies to ensure that tokens can be used only from trusted networks to access services. CAE offers a strict location enforcement mode to maximize protection. Find the step-by-step instructions for enabling this in our documentation.
Revoke tokens using Continuous Access Evaluation
In addition to ensuring that the supported services can only be accessed from trusted locations, CAE can revoke tokens when admins (or users themselves) take action in response to detecting an account compromise or token theft. These include disabling accounts, changing passwords, and revoking refresh tokens. Learn more about Continuous Access Evaluation in our documentation.
Use Entra ID Protection and Microsoft Defender to monitor for token theft. When a threat actor replays a token, their sign-in event can trigger detections such as ‘anomalous token’ and ‘unfamiliar sign-in properties’ from both Entra ID Protection and Microsoft Defender for Cloud Apps. Premium detections recognize abnormal characteristics such as an unusual token lifetime, a token played from an unfamiliar location, or token attributes that are unusual or match known attacker patterns. Signals from Microsoft Defender for Endpoint (MDE) can indicate a possible attempt to access the Primary Refresh Token.
Find step-by-step instructions for investigating token theft in our documentation.
Pull all your data into one Security Information and Event Management (SIEM ), such as Microsoft Sentinel, to investigate potential token theft. If you receive an alert for an event that may indicate token theft, you can investigate it in the Microsoft Sentinel portal or in another SIEM. Microsoft Sentinel gives you important details about a specific incident, such as its severity, when it occurred, how many entities were involved, which events triggered it, and whether it reflects any MITRE ATT&CK tactics or techniques. You can then view the investigation map to understand the scope and root cause of the potential security threat.
Find step-by-step instructions for investigating incidents using Sentinel in our documentation.
As defenders building defenses to help everyone strengthen cybersecurity, Microsoft is in a big strategic fight against token theft. We’ll keep you updated on any advancements you can use to counter attacks that use token theft. In the meantime, to help defend your environment, configure your Conditional Access policies to take advantage of token protection wherever you can and employ the countermeasures we’ve described here.
Stay safe out there,
Alex Weinert
Learn more about Microsoft Entra
Prevent identity attacks, ensure least privilege access, unify access controls, and improve the experience for users with comprehensive identity and network access solutions across on-premises and clouds.
Continue reading...
But as more customers do the right thing with MFA, actors are going beyond password-only attacks. So, we’re going to publish a series of articles on how to defeat more advanced attacks, starting with token theft. In this article, we’ll start with some basics on how tokens work, describe a token theft attack, and then explain what you can do to prevent and mitigate token theft now.
Tokens 101
Before we get too deep into the token theft conversation, let’s quickly review the mechanics of tokens.
A token is an authentication artifact that grants you access to resources. You get a token by signing into an identity provider (IDP), such as Microsoft Entra ID, using a set of credentials. The IDP responds to a successful sign-in by issuing a token that describes who you are and what you have permission to do. When you want to access an application or service (we’ll just say app from here), you get permission to talk to that resource by presenting a token that’s correctly signed by an issuer it trusts. The software on the client device you’re using takes care of all token handling behind the scenes.
Figure 1: Basic token flowThe first token you get, called a session token, shows that you successfully signed into the IDP, and how you signed in. When you sign into an app, it can exchange that session token for an access token, which gives you access to a specific resource for a certain amount of time without having to reauthenticate. To use an analogy, think of an amusement park. The IDP is the ticket office, which issues a park pass that provides credits for different rides. If you want to go on the roller coaster, you go to the ticket office, show your season park pass, and receive a ticket for that ride.
Just as you might be able to buy a day pass, season pass, or lifetime pass to the park, each token has a lifetime, usually between and 24 hours. And just as a 12-month season pass may get you a one-day pass to a specific ride, session tokens can have different—and usually much longer—lifetimes than access tokens. Moreover, access token lifetimes can differ, so the roller coaster pass may last an hour while the Ferris wheel pass is good for an entire day.
Traditionally, longer lifetimes are more convenient for users and more resilient against potential IDP outages (they save round trips to the IDP and associated latency) but riskier, while shorter lifetimes are safer (the IDP checks the integrity of the request more often). Technologies such as continuous access evaluation provide continuous assessment, so a shorter token lifetime isn’t a benefit when these are in place. When a token expires or continuous access evaluation reports heightened risk, the client goes back to the IDP and requests a refresh. This process is typically invisible to users, but if a risk condition has changed, and your organization policy requires it, then you may have to reauthenticate and get a new token. One last thing to note: while it’s a bummer to lose your roller coaster ticket, it’s really bad to lose your season park pass. An attacker can use your roller coaster ticket to get on a single ride for a short while, but with your season park pass, they can get on any ride for as long as they want. It’s similar with which, if stolen, give an actor a lasting ability to get access tokens.
How token theft works
Attackers steal tokens so they can impersonate you and access your data for as long as that stolen token lives. To do this, they get access to where a token is stored (on the client, in proxy servers, or in some cases in application or network logs) to acquire it and replay it from somewhere else.
Figure 2: Token theft cyberattack| Identity provider | Ticket office |
| Session token | Season park pass |
| Access token | Individual ride ticket |
When an attacker steals your session token, it’s like picking your pocket after you’ve purchased your all-access season park pass at the fair’s ticket office. Because a token is digital, token theft is like stealing the pass from your pocket, making a photocopy, and then putting the original back in your pocket. The attacker can use their copy of your session token to get unlimited new access tokens to keep stealing your data, just as they can show a copy of a valid park pass to keep getting on rides without paying.
An attacker stealing your access token is comparable to someone and stealing your ride ticket as you stand in line. They do the same copy-and-replace trick, using their copy of your token to access the resource, just as they could show a copy of a valid ticket to get on an individual ride without paying.
And because in both cases the attacker puts the original pass or ticket back in your pocket, you don’t even know an attacker is riding the rides in your name. Your token seems fine, even though an attacker is using an illegitimate copy of it, and it may take a while to determine that anything is amiss—if you ever do.
Here’s an example:
Contoso stores all their documents in a secure cloud storage service and requires all employees to verify their identity using MFA before accessing it.
One day, after starting their workday by signing into Contoso's cloud storage service, a user inadvertently installed malware on their device by clicking on a malicious 'phishing' link sent to them via email. The malicious code copied the user's session token and sent it to the attacker.
The attacker then used the stolen and MFA-validated session token, now copied to their machine, to gain access to Contoso's environment.
The attacker then downloaded as many documents as they could access, including a bunch of confidential reports, and leaked them on the internet.
Use of malware on the client to acquire the token is one common, easy method for attackers. Other tactics used to steal tokens include:
- Copying tokens from the network as they pass through a proxy or router that the attacker controls.
- Extracting tokens from unsecured server logs of the relying party.
While token theft still constitutes fewer than 5% of all identity compromises, incidents are growing. alone, we detected 147,000 token replay attacks, a 111% increase year-over-year.
Protecting tokens
IDPs and clients should handle tokens as securely as possible by only transmitting them over encrypted channels and not storing them in the open. But if an attacker infiltrates the device or network channel as in the example above, they can steal tokens and use them until they expire.
Ideally, a token would only work when used from the device to which it was issued. That is, if replayed from a different device, such as one an attacker controls, the would be rejected.
A key part of Microsoft’s protections against token theft is the use of tokens that are cryptographically tied to the device they . This is often called token binding, but may also be called sender constrained tokens, or token proof of possession. Token protection makes it harder to execute the main types of attacks designed to steal tokens, including network-based attacks and those using malware on the device by restricting use of the stolen token from devices they weren't issued to.
In Microsoft Entra, token protection binds tokens to cryptographic keys specific to the device and ties them to the device registration. Once developers enable their applications to use protected tokens, you can enforce an Entra Conditional Access policy that requires client applications to use protected tokens to access a service. This policy rejects tokens which are not cryptographically tied to the device they were issued to. In the theme park analogy, this is like the ticket office taking your picture and printing it on your ride ticket and requiring ride operators to match the picture to your face before letting you ride.
Figure 3: Token protection in Microsoft EntraThis is a large project, spanning operating system platforms, native and web applications, all our cloud services, and the full range of different tokens in use for each case. It will be released in stages for specific scenarios. The first stage, in public preview now, protects the sign-in session tokens that native applications on Windows devices use when accessing Exchange, SharePoint and Teams services.
Token protection policy is available for Windows clients today. We’ll support Azure management scenarios and web applications that access Microsoft 365 resources and extend our cross-platform capabilities to Mac, iOS, Android, and other clients over the next year.
Practical steps for countering token theft
Token protection will offer the strongest protection against token theft; however, it will take the industry time to update all applications to use bound tokens. The good news is that Microsoft offers compelling countermeasures against attacks involving token theft that you can use today to reduce their risk and impact. We recommend a systematic defense-in-depth approach:
- Reduce the risk of successful token theft.
- Prevent malicious use of stolen tokens.
- Be prepared to detect and investigate attacks that use stolen tokens.
Reduce the risk of successful token theft
The first line of defense is to reduce the chances of attackers stealing tokens in the first place, and below are some well-established techniques for building it. It’s the equivalent of keeping your ride tickets and park passes safe from pickpockets while you’re in the theme park.
Require managed and compliant devices. Use device management and define Conditional Access policies to require that users access resources from a compliant device. Compliance policies we recommend to reduce the risk of successful token theft from devices include:
- To help prevent accidental infection with token-stealing malware, require users running on Windows to run as standard users rather than with device admin rights and require that all devices run up to date anti-malware and virus tools.
- Use storage encryption to protect device content, including tokens, in case someone steals the device itself.
- Enable Local Security Authority (LSA) protection to help protect Entra ID tokens in LSA memory. LSA protection is on by default for new devices and can be enabled for other devices via Intune.
- Use jailbreak or rooting detection for mobile devices. Jailbroken devices are more likely to expose tokens and cryptographic secrets to potential attacks.
Find step-by-step instructions for enabling credential guard in our documentation.
Turn on Credential Guard for your Windows users. If your users are running Windows 10 or later, you can prevent theft of Active Directory credentials by configuring Credential Guard, which us es virtualization-based security (VBS) to isolate local and cached credentials so that only privileged system software—and not malware—can access them. Starting in Windows 11, version 22H2, Credential Guard is on by default for devices that meet requirements. This also helps protect cloud applications and resources when hybrid-joined devices using Active Directory authentication initiate a session to access cloud applications.
Find step-by-step instructions for enabling credential guard in our documentation.
Prevent malicious use of stolen tokens
While device management and strong credentials certainly reduce the risk of token theft, not everyone has them, and they’re still not completely foolproof. The next layer of defense is to prevent attackers from using stolen tokens for ongoing access by configuring policies to reject them wherever possible, and by detecting attempted use and responding automatically.
Require token protection in Conditional Access, and where possible, choose apps and services that use token protection. Microsoft is updating our apps, identity provider, and operating systems to support token protection, so if you’re using our apps and platforms, be sure to use the latest versions. Then configure Conditional Access to require token protection for sign-in sessions so only applications and devices using bound sign in session tokens, which can’t be used if they’ve been stolen and moved to another device.
Find step-by-step instructions for creating a Conditional Access policy that requires token binding in our documentation.
Create a risk policy to disrupt token theft in your environment automatically. When a user initiates a session or attempts to access an application, ID Protection will examine user and session risk factors to see if any have changed. Configure Conditional Access policies to protect both medium and high-risk sessions by either challenging users with MFA or by requiring reauthentication. This will make it difficult or impossible for an attacker to initiate a session using a stolen session token.
Wherever available, Continuous Access Evaluation (CAE) can automatically invalidate tokens when ID Protection raises the risk for a user or a service principal. This triggers the risk-based Conditional Access policies to mitigate in real-time, requiring re-authentication.
Find step-by-step instructions for creating risk-based Conditional Access policies in our documentation.
Reduce the risk of token reuse by restricting sessions for use within network boundaries. Most attackers use stolen tokens from untrusted IP addresses. You can establish network boundaries with policies that prevent users from accessing your resources if they’re coming from unknown locations or from known bad locations.
Restrict networks with Entra Conditional Access: Conditional Access includes controls that will block requests from outside a network compliance boundary that you define. This will prevent an attacker from refreshing a stolen Entra token, restricting its use to the lifetime of the token.
Find step-by-step instructions for defining a network compliance boundary with Conditional Access in our documentation.
Enhance network controls with Microsoft’s Security Service Edge (SSE) solution: To prevent the attacker from using a token outside of a trusted network at all, Entra Internet Access and Entra Private access use agents installed on endpoints and a compliant network check (enforced in real-time via CAE) to verify whether a user is connecting from a trusted network. Find step-by-step instructions for enabling compliant network check with Conditional Access in our documentation.
CAE-capable applications and services such as Teams, Exchange Online, and SharePoint Online will continuously enforce the IP-based named location Conditional Access policies and compliant network policies to ensure that tokens can be used only from trusted networks to access services. CAE offers a strict location enforcement mode to maximize protection. Find the step-by-step instructions for enabling this in our documentation.
Revoke tokens using Continuous Access Evaluation
In addition to ensuring that the supported services can only be accessed from trusted locations, CAE can revoke tokens when admins (or users themselves) take action in response to detecting an account compromise or token theft. These include disabling accounts, changing passwords, and revoking refresh tokens. Learn more about Continuous Access Evaluation in our documentation.
Be prepared to detect and investigate attacks that use stolen tokens
Use Entra ID Protection and Microsoft Defender to monitor for token theft. When a threat actor replays a token, their sign-in event can trigger detections such as ‘anomalous token’ and ‘unfamiliar sign-in properties’ from both Entra ID Protection and Microsoft Defender for Cloud Apps. Premium detections recognize abnormal characteristics such as an unusual token lifetime, a token played from an unfamiliar location, or token attributes that are unusual or match known attacker patterns. Signals from Microsoft Defender for Endpoint (MDE) can indicate a possible attempt to access the Primary Refresh Token.
Find step-by-step instructions for investigating token theft in our documentation.
Pull all your data into one Security Information and Event Management (SIEM ), such as Microsoft Sentinel, to investigate potential token theft. If you receive an alert for an event that may indicate token theft, you can investigate it in the Microsoft Sentinel portal or in another SIEM. Microsoft Sentinel gives you important details about a specific incident, such as its severity, when it occurred, how many entities were involved, which events triggered it, and whether it reflects any MITRE ATT&CK tactics or techniques. You can then view the investigation map to understand the scope and root cause of the potential security threat.
Find step-by-step instructions for investigating incidents using Sentinel in our documentation.
| Reduce the risk of successful token theft | Prevent malicious use of stolen tokens | Be prepared to detect and investigate attacks that use stole tokens |
| Require managed and compliant devices. Turn on Credential Guard for your Windows users. | Require token protection in Conditional Access and where possible, choose apps and services that use token protection. Create a risk policy to disrupt token theft in your environment automatically. Reduce the risk of token reuse by restricting sessions for use within network boundaries. Revoke tokens using Continuous Access Evaluation | Use Entra ID Protection and Microsoft Defender to monitor for token theft. Pull all your data into one SIEM, such as Microsoft Sentinel, to investigate potential token theft. |
As defenders building defenses to help everyone strengthen cybersecurity, Microsoft is in a big strategic fight against token theft. We’ll keep you updated on any advancements you can use to counter attacks that use token theft. In the meantime, to help defend your environment, configure your Conditional Access policies to take advantage of token protection wherever you can and employ the countermeasures we’ve described here.
Stay safe out there,
Alex Weinert
Learn more about Microsoft Entra
Prevent identity attacks, ensure least privilege access, unify access controls, and improve the experience for users with comprehensive identity and network access solutions across on-premises and clouds.
- Microsoft Entra News and Insights | Microsoft Security Blog
- Microsoft Entra blog | Tech Community
- Microsoft Entra documentation | Microsoft Learn
- Microsoft Entra discussions | Microsoft Community
Continue reading...