In Part 02, we explored authentication, the process of verifying user identities—ensuring users are who they claim to be. Today we’ll build on that by diving into authorization—the process of determining what authenticated users are allowed.

While authentication is a foundational element of any organization’s identity and access management strategy, secure identity verification alone isn’t sufficient. Authorization completes the picture by assigning the correct permissions and controls, ensuring users have exactly the access they need—no more, no less. Today we'll tackle exactly that—Authorization in a Microsoft Business Premium Environment.
Let’s dive in!
Table of Contents
Understanding Microsoft Business Premium Authorization: Authentication vs. Authorization
The Evolution from Perimeter-Based Security to Zero Trust Authorization
Microsoft Entra Conditional Access: Your First Line of Defense
Best Practices and Pitfalls of Microsoft Entra Conditional Access
Microsoft Entra Business Premium Conditional Access Baseline Policies
Importable Policies for the Baseline Conditional Access Setup
Conclusion: Securing Access – The Key to Effective Authorization and Risk Management
Understanding Microsoft Business Premium Authorization: Authentication vs. Authorization
I often see the terms AuthN and AuthZ used interchangeably, though they serve different purposes.
Authentication (AuthN)
Authentication is the process of verifying or validating an identity before granting access. In other words, it confirms that you are who you claim to be.
Authentication occurs before Authorization (AuthZ) and does not directly provide any permissions.
The Microsoft identity platform uses OpenID Connect (OIDC) for authentication.
Authorization (AuthZ)
Authorization is the process of granting an authenticated identity, whether human or non-human, specific permissions. This can be achieved using Microsoft’s built-in systems, such as Entra and RBAC roles, or through the OAuth 2.0 protocol for custom applications.
Authorization takes place after successful authentication and is only applicable to identities that have passed the authentication process.
The Evolution from Perimeter-Based Security to Zero Trust Authorization
Historically, organizations trusted authenticated internal users within the corporate network, while distrusting external traffic and users. This old-school approach assumed internal threats were minimal. However, modern threats—including phishing attacks, compromised credentials, and insider risks (both malicious and unintentional)—have proven that perimeter security alone is insufficient.
Instead, organizations need to adopt a Zero Trust strategy built on the principle of “Never trust, always verify.” This approach ensures granular, context-aware access control, significantly reducing organizational risk. Microsoft Business Premium supports these principles directly through tools like Conditional Access, Administrative Units, and secure collaboration via Cross-Tenant Sync, empowering organizations to implement effective Zero Trust authorization strategies.
Proper utilization of access control helps mitigate risks such as privilege creep, over-privileged accounts, and helps protect against data theft, corruption, and exfiltration.
Microsoft Entra Conditional Access: Your First Line of Defense
In our security toolkits, one of the strongest tools we have is Conditional Access (CA). CA allows us to enforce strict controls over Authorization (AuthZ) for authenticated users.
This means that CA is applied after authentication, but before authorization is granted.
I’ve got a full series on Conditional Access, starting with Part 1. Feel free to dive deeper into that series for further understanding.
What is Microsoft Entra Conditional Access?
In simple terms, Conditional Access allows us to enforce specific conditions, requirements, and session controls before granting access to an application or action.
These conditions can include filtering based on:
Specific devices
User roles
Locations
Risk levels
Platforms
We can also enforce strict Authentication methods (as we covered in Part 02) or set policies on how often users need to re-authenticate.
These are just a few examples of the powerful controls CA provides, making it a cornerstone for ensuring only the right people have access at the right time.
Why is Microsoft Entra Conditional Access Critical?
As mentioned earlier, it is critical to enforce strict and continuous requirements for all access attempts, whether internal or external. This ensures that only the right users have the right permissions at all times.
By enforcing Zero Trust principles—specifically Verify Explicitly, Least Privileged Access, and Assume Breach—we ensure that no malicious actor gains access, and that unintentional leaks of critical business data, infrastructure, or Personally Identifying Information (PII) are prevented.
Best Practices and Pitfalls of Microsoft Entra Conditional Access
As with any tool, there are best practices to follow, as well as pitfalls to avoid when configuring Conditional Access. Let’s explore some of them:
Best Practices
Utilize Persona-Based Configurations:
Creating different personas helps with granular access controls, auditing, license requirements, and compliance. It also simplifies managing groups based on common or scoped access needs.
Personas are essentially groups created to hold identities that share common access needs, and they can be either static or dynamic groups.
Common personas include:
Internal Administrators
Guest Administrators
Breakglass Accounts
Guest Users
Service Accounts
Global Users
Developers
Add Trusted Locations:
While it’s rare to include trusted locations directly in CAPs, configuring trusted locations enhances security. Known and trusted locations will trigger a Continuous Access Evaluation (CAE) Token, which can revoke active tokens (even within their lifetime) if critical changes occur, such as a password reset, user disablement, or location change.
How to configure trusted locations:
Navigate to Named Locations in the Conditional Access menu.
Click on IP Ranges Location, give it a name, and add the required IP Ranges.
Enable the Mark as Trusted Location option.
Set Policies to “Report-Only” Mode:
Enforcing new Conditional Access policies can be disruptive, especially if they contain strict requirements that your environment isn’t ready for. Always start by setting new policies to Report-Only mode, so you can assess their impact before enforcing them.
Test and Validate Policies:
Utilize the What-If Tool and conduct a gradual rollout of new policies to ensure smooth deployment and enforcement.
Utilize insights and reporting - Streaming Entra logs to a log analytics workspace allows for using the dashboard Conditional Access insights and reporting
Utilize Insights and Reporting:
Streaming Entra logs to a Log Analytics Workspace enables you to leverage the Conditional Access Insights and reporting dashboard for comprehensive reporting.
Configuring diagnostics settings:
Navigate to Diagnostics Settings under Monitoring & Health.
Configure logs to be collected in a Log Analytics Workspace in Azure.
Alternatively, the new Policy Impact (Preview) feature provides valuable insights on the historic impact of a given policy, even without collecting logs, offering cost-effective analysis.
Pitfalls to avoid & be aware of
Authentication Strengths:
Enforcing a specific Authentication Strength can lock users out if they don’t have the required authentication method available or the option to configure it. Ensure Authentication Strengths and Authentication Methods are gradually enforced and properly configured to avoid disruption.
Conditional Access Evaluated as AND Statements:
Conditional Access policies are always evaluated as AND statement. This means that if any applied policy evaluates to block access, access will be denied, even if other policies would allow it. Be mindful of how your policies are structured and test them.
Microsoft Entra Business Premium Conditional Access Baseline Policies
Once again, I highly recommend checking out my dedicated Conditional Access series, where I explain the importable policies, provide an overview of persona-based policies, and discuss the naming conventions used for easier management.
The full series includes:
Microsoft Entra Conditional Access Series (Part 1): The Essentials
Microsoft Entra Conditional Access Series (Part 2): Managing Privileged Identities
Microsoft Entra Conditional Access Series (Part 3): Policies for Non-Human Identities
Microsoft Entra Conditional Access Series (Part 4): Mastering Risk-Based Policies
Microsoft Entra Conditional Access Series (Part 5): Application-Specific Protections
These resources will help you build a comprehensive Conditional Access strategy tailored to your organization’s needs.
With that said, the following 12 policies are essential for any environment and should be deployed as a baseline:
Block Legacy Authentication
Block Unknown & Unsupported Platforms
Block Non-Business Countries
Require MFA for Security Info Registration
Require MFA for All Users
Require MFA for All Guest Users
Require Phishing-Resistant MFA for Admins
Require Phishing-Resistant MFA for Breakglass Accounts
Require TOU for Security Info Registration for Guest Users
Require App Protection Policy for O365 Apps
Restricted Session Lifetime for Unmanaged Devices
Restricted Session Lifetime for Managed Devices
These policies cover a significant portion of an SMB environment’s security needs, providing a strong foundation to build upon.
Importable Policies for the Baseline Conditional Access Setup
Here are the 12 policies, visualized with links to the importable JSONs:
CAP 01: Block Legacy Authentication
CA000-Block-BaselineProtection-Global-AllApps-AnyPlatform-Block legacy authentication v1.0

CAP 02: Block Unknown platforms
CA001-Block-DeviceProtection-Global-AllApps-WindowsPhone-Block Unknown platforms v1.0

CAP 03: Block countries without business
CA002-Block-AttackSurfaceReduction-Global-AllApps-AnyPlatform-Block non-business countries v1.0

CAP 04: Enable MFA for all users
CA500-MFA-BaselineProtection-Global-AllApps-AnyPlatform-Require MFA for all users v1.0

CAP 05: Require MFA for registering security info
CA501-MFA-BaselineProtection-Global-CombinedRegistration-AnyPlatform-Require MFA for registering security info v1.0

CAP 06: Require App Protection Policy for mobile applications
CA502-APP-Data&AppProtection-Global-O365-iOS&Android-Require App Protection Policy v1.0

CAP 07: Session lifetime for managed devices
CA503-SessionControl-DataProtection-Global-AllApps-AnyPlatform-8H session lifetime for managed devices v1.0

CAP 08: Session lifetime for unmanaged devices
CA504-SessionControl-DataProtection-Global-AllApps-AnyPlatform-3H session lifetime for unmanaged devices v1.0

CAP 09: Enable Phishing-resistant MFA for Admins
CA600-AuthStr-IdentityProtection-Admins-AllApps-AnyPlatform-Require Phishing-Resistant MFA for Admin roles v1.0

CAP 10: Enable MFA for all externals
CA700-MFA-BaselineProtection-Guests-AllApps-AnyPlatform-Require MFA for all guest users v1.0

CAP 11: Require Term of Use acceptance by guest users for Security info registration
CA706-TOU-ComplianceProtection-Guests-CombinedRegistration-AnyPlatform-Require TOU for security info for Guests v1.0

CAP 12: Require Phishing-Resistant Authentication for Breakglass Accounts
CA900-AuthStr-IdentityProtection-Breakglass-AllApps-AnyPlatform-Require Phishing-resistant Authentication for BreakGlass Accounts v1.0
NOTE: This should be scoped to only allow for specific hardware passkeys, ensuring that only the most secure authentication methods are used for Breakglass Accounts.

These CAPs will provide a solid baseline that covers about 90% of the sign-ins and actions within an SMB environment, laying a strong foundation for further security enhancements.
By implementing these policies, you are taking a critical step toward ensuring that your organization adheres to the principles of Zero Trust and maintains control over who accesses your resources.
Microsoft Stack Permissions Recommendations
Insights & Reporting
In many environments, particularly within the SMB segment, access permissions are often poorly managed. Multiple internal and external admins, changing recommendations, and evolving requirements, compounded by the growth of Microsoft cloud environments, have led to a situation where no one truly knows who, what, or why someone has the permissions they do. Oftentimes, there’s no clear overview of the currently assigned permissions.
To address this, the first step I recommend is extracting all permissions across the Microsoft cloud for all types of identities—whether internal, external, users, apps, etc.—and reviewing their permissions, scopes and last sign-in data.
I’ve developed a solution to assist with this, which I will walk through in this blog post.
Administrative Units: Segmenting Access for Better Control
To ensure that no one is granted broader or higher privileges than necessary, it’s crucial to manage the scope of assigned permissions effectively. One way to achieve this is by utilizing Administrative Units (AUs). AUs are logical groupings of users, devices, and permissions, similar to Organizational Units (OUs) in on-premises Active Directory.
AUs allow us to restrict permissions to only a subset of users, devices, or groups, providing scoped permissions. This ensures that access is granted only where needed, while still allowing higher-level permissions for administrators who require access across the entire organization.
For example, if you work with multiple partners that have different responsibility areas, such as geographic zones, you can scope permissions to those areas to ensure that privileged users can only manage resources within their designated zones.
I recommend creating AUs based on logical responsibility zones, such as geographic, departmental, or partner-based groupings.
Restricted Management Administrative Units: Restricted Permissions for Enhanced Control
In addition to using AUs, you can further refine your control with Restricted Management Administrative Units (RMAUs). RMAUs remove the hierarchical permissions naturally granted by AUs.
This means that permissions granted at a higher scope will not apply to objects within the RMAU, providing an additional layer of security.
Example:
Let’s say Helpdesk needs access to create TAPs for users who cannot access their configured authentication methods.
However, the Helpdesk team should not have access to manage authentication methods for privileged users or critical accounts, such as C-level executives.
By assigning the Entra Built-in role Authentication Administrator to the Helpdesk team, they would typically have broader access. However, using an RMAU, you can ensure that the Helpdesk’s role doesn’t extend to managing authentication methods for these high-level accounts.
I recommend using RMAUs to restrict permissions for critical non-privileged users, devices, and groups, ensuring tight control over who can access what.
Recommended License Step-up - Microsoft Entra Premium P2
While the BP SKU is robust, it doesn’t include all the features that might be necessary. One such feature is Privileged Identity Management (PIM), which provides time- and approval-based permission elevations. PIM is particularly valuable for restricting permissions, especially for highly privileged roles like Global Administrators.
I will dive deeper into the PIM feature in this blog post.
PIM is part of the Microsoft Entra Premium P2 license. As part of the Entra product line, it follows the principle of 1 employee, 1 license, meaning you can purchase a P2 license for each admin and use the P2 features across all their accounts, without needing to buy a separate license for each individual account.
I highly recommend purchasing P2 licenses for your admins and utilizing PIM for managing privileged roles, along with Authentication Context for elevation requests. This will greatly enhance the security of your privileged accounts and strengthen your Authorization policy.
Conclusion: Securing Access – The Key to Effective Authorization and Risk Management
Authorization is the backbone of a well-rounded Identity and Access Management strategy. Without proper enforcement of Conditional Access (CA), Role-Based Access Control (RBAC), and Administrative Units (AUs), organizations risk privilege creep, unauthorized access, and gaps in their security posture.
By leveraging Zero Trust principles, implementing Conditional Access policies, and utilizing Microsoft Entra’s security capabilities, businesses can ensure that only the right individuals have the right access at the right time—no more, no less.
Now with all that said, according to tradition, here's another bad joke:
How do you catch a runaway laptop?
With an internet! 😎
By implementing these strategies, organizations can transition from static permissions to dynamic, role-based controls, aligning their security approach with modern challenges while minimizing risks. This ensures a more adaptive and responsive system that not only protects resources but also supports ongoing organizational growth.
As we move forward in this series, I encourage you to take action on the tips shared here to strengthen your organization’s authorization framework. Stay tuned for the next post, where we’ll dive deeper into even more advanced strategies for enhancing your Microsoft security stack.
Make sure to bookmark this post for future reference as we continue to build on these concepts in the upcoming parts of the series.
🔗 Securing Microsoft Business Premium Series Post Index
Part 03: Authorization Best Practices from Zero Trust to Complete Access Control (You're here!)