Top 10 Entra & Intune Security Tips

This year at Geekmania 2025, I had the pleasure of sharing the stage with Niklas Tinner for a deep-dive session into one of the most critical and rapidly evolving areas of modern IT security: Microsoft Entra & Intune Security.
Together, we explored practical, proven strategies to harden identity, streamline device compliance, and reduce attack surface — without making life harder for users or administrators.

Our goal was simple: turn best-practice knowledge into actionable steps organizations can implement immediately. The feedback was fantastic, and many attendees asked for a written summary — so here it is.

Below you’ll find the Top 10 Entra & Intune Security Tips we covered on stage. As this is a collaboration post, you finde the other half on Niklas's Blog:

http://www.oceanleaf.ch/top-10-entra-intune-security-tips/

Platform Restrictions

One key element we emphasized during the session is the importance of Intune Platform Restrictions. Allowing any device to enroll into your environment may seem convenient at first, but it opens the door for unmanaged, unknown, or potentially compromised endpoints.
If your operating system enrollment is left unrestricted, any device — corporate or not — could gain access. This risk grows even faster in hybrid or remote-first environments.

Unless you are running a clearly defined and well-governed BYOD strategy, you should strictly limit which platforms and OS versions are allowed to enroll in Intune. By enforcing enrollment restrictions, you:

• Prevent unknown endpoints from becoming part of your trusted environment
• Reduce your overall attack surface dramatically

Platform controls are not just a configuration option — they are a fundamental security boundary. A clean, controlled device landscape is one of the strongest steps toward a resilient and enforceable Zero Trust posture.

Intune Portal > Devices > Enrollment > Device Platform restrictions

WHfB Cloud Trust

When moving towards a passwordless future, Windows Hello for Business (WHfB) plays a major role — but the real power unfolds when combined with Kerberos Cloud Trust.
With this approach, users no longer need to fall back to traditional passwords when accessing on-premises resources such as file shares, legacy apps, print servers or internal web systems. Instead, authentication is completed seamlessly and securely using strong key-based credentials.

Kerberos Cloud Trust removes complexity from certificate deployments, eliminates multiple trust anchors and provides a more streamlined, scalable experience for hybrid environments. Instead of juggling certificates or maintaining PKI dependencies just to replace passwords, you enable secure access with modern authentication backed directly by Entra ID.

The benefits are significant:

• Passwordless authentication all the way — even for on-prem workloads
• No more certificate trust or key trust infrastructure overhead
• Easy deployment with minimal configuration requirements
• Reduced phishing risk due to strong, non-replayable credentials
• Better user experience with fast and frictionless sign-in

Here a quick view of my summary (in German)

It is based on two configurations:

1. Entra ID Connect on the Server
2. Intune Settings Catalog

Powershell Script which you have to run on a server where your Entra ID Connect is running (With Domain Admin Privileges, as it creates an AD, RODC Object)

$domain = $env:USERDNSDOMAIN
$userPrincipalName = "albin@indefent.com"
Set-AzureADKerberosServer -Domain $domain -UserPrincipalName $userPrincipalName -SetupCloudTrust

Setting which you have to configure in Intune within the settings Catalog:

Devices > Manage devices > Configuration > Create > New Policy

In your WhfB Configuration, then enable the usage of Cloud Trust:

To ensure that authentication is truly happening via Kerberos Cloud Trust and that passwordless Kerberos tickets are being used, you can verify it directly on the client.

Via CMD
Use the following commands to view and debug Kerberos tickets:

klist
klist cloud_debug

This allows you to check whether a valid ticket exists and which mechanism issued it.

Via Event Viewer:
You can also confirm the status in the Event Viewer:

Applications and Services Logs → Microsoft → Windows → User Device Registration

Look for Event ID 358, which indicates that WHfB Kerberos Cloud Trust has been successfully registered and provides detailed information on whether authentication was completed correctly.

Privileged Identity Management (PIM)

Privileged Identity Management (PIM) in Entra ID (available with Premium Plan 2) is all about securing administrative access in a modern, Zero Trust approach. It’s designed to ensure that elevated permissions are only granted just-in-time, just-enough, and with accountability — so you’re never leaving “superpowers” lying around unused. Importantly, PIM is relevant only for administrators, and licenses are only required for those users.

With PIM, organizations can:

• Control access precisely – Ensure the right people have the right permissions at the right time.
• Require approvals – Implement a dual-control system where sensitive role activations need approval before being granted.
• Monitor and audit – Track role activations, collect justifications for access, and report on elevated actions.

PIM forces you to think critically about privileged actions, justify why you need them, and carefully select the minimum set of permissions necessary.

Why Privileged Identities Matter

A Privileged Identity is any account that can make impactful changes across your systems — essentially, someone with “superpowers.” In the Microsoft cloud ecosystem, these privileges could allow someone to:

• Lock or unlock user accounts
• Wipe or manage devices
• Add or remove third-party applications
• Modify data in SharePoint, OneDrive, or Teams

Because these accounts have such broad and potentially risky powers, protecting them is critical. PIM helps, but it’s not enough on its own. To truly secure privileged identities, you should also combine PIM with:

• Strong MFA or phishing-resistant authentication
• Conditional Access policies for sensitive operations
• Proper secret management and secure storage
• Trusted endpoints and devices to ensure defense-in-depth

In short, PIM is your framework for thinking before acting with powerful accounts — ensuring control, visibility, and security at every step.

Additionally the authentication context to your PIM configuration is crucial - you should use auth. context's as well on your Entra Roles:

If you are looking for a guide on how to configure PIM - here you go:

Privileged Identity Management (PIM) concept + setup

Introduction Privileged Identity Management (PIM) is no longer a hidden gem in the Microsoft cloud ecosystem. It was originally released almost 10 years ago! I know there is already a lot of great content out there on it, but this blog post will be my personal summary. What to expect

OceanleafNiklas Tinner

Authentication Context

An Authentication Context in Microsoft Entra ID is a way to apply additional security requirements to specific sensitive operations or resources. It allows you to define conditions or policies that must be satisfied for a particular action, independent of normal sign-in requirements.

Think of it as saying: “This action is so sensitive that it requires stronger verification than a standard login.”

Why Use Authentication Contexts?

Authentication Contexts are especially powerful when combined with Privileged Identity Management (PIM) and phishing-resistant authentication:

1. Protect high-risk actions – Examples include activating privileged roles, accessing critical applications, or performing financial transactions.
2. Enforce phishing-resistant methods – By requiring FIDO2 keys, Windows Hello for Business, or certificate-based authentication, you make it nearly impossible for attackers to bypass MFA via stolen credentials.
3. Granular access control – Different actions can require different authentication strengths depending on risk or sensitivity.
4. Seamless integration with PIM – When a user requests elevation via PIM (e.g., activating Global Administrator), an Authentication Context can enforce a strong verification method before access is granted.

Example Scenario

Imagine an admin needs to activate the Global Administrator role via PIM. Normally, MFA might suffice. With an Authentication Context enforcing phishing-resistant authentication, the user would be required to use a FIDO2 security key or WHfB key trust login. This adds a layer of protection even if the user’s password or standard MFA is compromised.

The result: High-risk operations are protected by strong, verifiable authentication methods, reducing the likelihood of account takeover and ensuring compliance with a Zero Trust approach.

For the configuration you need:

• Authentication Context configured

• CA Policy where you use the Authentication Context

After you have configured the authentication context, you can now go ahead and set the authentication context like in this scenario for the proteced actions so the CA Policy comes in whenever a protected action is done.

Protected Actions

Protected Actions in Microsoft Entra ID are sensitive operations that can have a major impact on your identity security. These are actions that, if performed by a malicious actor or misconfigured user, could compromise accounts, elevate privileges, or otherwise weaken your security posture.

Protected Actions include the following Permissions:

In short, Protected Actions let you segregate sensitive identity operations from everyday user activity and add layers of control to prevent misuse or compromise. Treating these actions differently is a core part of a Zero Trust identity strategy.

I recommend you to add all permissions to it.
you find the configuration under: Roles & admins > Protected actions

You only have to "Add protected actions" and choose which actions you want to protect - again, choose all of them to ensure all operations are proteced.

Ensure as well, you have a proper authentication context (as described above) configured.

Security Info Registration

One often overlooked but critical step in identity security is protecting the Security Info (MFA) registration process. If left unprotected, an attacker who gains initial access — for example via a compromised account or stolen password — could register their own MFA device. This would give them persistent access to your environment, bypassing your security controls.

By enforcing a Conditional Access (CA) policy specifically for Security Info Registration, you can ensure that:

• Only trusted locations, devices, or networks can perform MFA registration
• Attackers cannot add MFA methods outside your organization
• Users are forced to follow secure, compliant registration flows
• Risk of account takeover is dramatically reduced

Think of it as locking the door before someone can change the locks. It’s not enough to just enforce MFA — you also need to protect the process that configures MFA, because that’s a high-value attack vector.

🔥 Final Thoughts

Identity and Endpoints arethe core of modern security, and Microsoft Entra provides incredibly powerful tools — if you use them well. Start small, improve continuously, automate where possible and keep your environment clean. Security isn’t a finish line, but a journey.

More examples, scripts and deep dives are coming soon — stay tuned.
If you missed the session or want to talk Entra architecture, governance or zero trust strategy, I’m always happy to connect.

A big thanks to Niklas Tinner for sharing the stage and André Pflaum for organizing such an amazing Event!