## Why Microsoft Entra ID security matters for SMBs
For many small and midsize businesses, Microsoft 365 is no longer just email and Office apps. It is the identity provider for email, SharePoint, OneDrive, Teams, SaaS applications, VPN access, remote desktops, and sometimes line-of-business systems. That makes Microsoft Entra ID, formerly Azure Active Directory, one of the most important security control planes in the business.
Attackers understand this. A compromised Microsoft 365 account can be used to read sensitive email, change mailbox forwarding rules, approve fraudulent invoices, access cloud files, register malicious OAuth applications, and move laterally into other systems. In real incidents, the initial technical issue is often simple: no enforced MFA, stale admin accounts, weak legacy authentication controls, or no alerting when risky sign-ins occur.
The good news is that SMBs can dramatically reduce identity risk with a practical Entra ID baseline. This does not require an enterprise security team, but it does require discipline. The goal is to make identity compromise harder, make administrative actions safer, and make suspicious activity visible before it becomes a business interruption.
This guide outlines a field-tested Microsoft Entra ID security baseline suitable for technically inclined business owners, internal IT staff, and managed service providers supporting SMB environments.
## Start with an identity inventory
Before enabling policies, document what you have. Identity security projects fail when teams deploy controls without knowing which accounts, applications, devices, and authentication methods are in use.
At minimum, inventory the following:
– Global administrators and other privileged roles
– Shared mailboxes and service accounts
– Guest users and external collaborators
– Registered enterprise applications and app permissions
– Devices joined to Entra ID or hybrid joined
– Users without MFA registration
– Sign-in activity for stale accounts
– Conditional Access policies already configured
– Licensing available for security features
You can collect some of this information from the Microsoft Entra admin center, but PowerShell is useful for repeatable reviews.
### Example: list directory roles and members with Microsoft Graph PowerShell
“`powershell
Install-Module Microsoft.Graph -Scope CurrentUser
Connect-MgGraph -Scopes ‘Directory.Read.All’,’RoleManagement.Read.Directory’,’User.Read.All’
$roles = Get-MgDirectoryRole
foreach ($role in $roles) {
Write-Host “`nRole: $($role.DisplayName)”
Get-MgDirectoryRoleMember -DirectoryRoleId $role.Id | ForEach-Object {
$member = Get-MgUser -UserId $_.Id -ErrorAction SilentlyContinue
if ($member) { Write-Host ” – $($member.UserPrincipalName)” }
}
}
“`
If you discover five global admins for a 40-person company, that is not unusual, but it is a risk. Most users do not need standing administrative access. Rights should be assigned intentionally and reviewed regularly.
## Establish two break-glass accounts
Every Entra ID tenant should have emergency access accounts, often called break-glass accounts. These are cloud-only accounts used only when normal authentication or Conditional Access policies prevent administrators from accessing the tenant.
A good break-glass design includes:
– Two cloud-only accounts, not synchronized from on-premises Active Directory
– Long, randomly generated passwords stored in a secure offline or escrowed location
– Exclusion from Conditional Access policies that could lock out all admins
– Global Administrator role assigned only to these emergency accounts and a minimal admin group
– Monitoring and alerting for any sign-in attempt
– No mailbox license and no daily operational use
Do not use a personal admin account as your break-glass account. Also do not protect break-glass accounts with the same MFA dependency that could fail during an outage. Instead, compensate with extreme password strength, restricted use, and alerting.
### Practical monitoring tip
Create an alert for any sign-in to emergency accounts. In environments using Microsoft Sentinel, a simple query can identify activity:
“`kusto
SigninLogs
| where UserPrincipalName in (‘[email protected]’,’[email protected]’)
| project TimeGenerated, UserPrincipalName, IPAddress, AppDisplayName, ResultType, ResultDescription
“`
If you do not have Sentinel, review Entra ID sign-in logs and configure email alerts through available Microsoft security portals or your managed detection platform.
## Enforce phishing-resistant MFA where possible
MFA remains one of the highest-value controls for Microsoft 365 security, but not all MFA is equal. SMS and voice calls are better than passwords alone, but they are vulnerable to SIM swapping, social engineering, and fatigue-based attacks. Number matching in Microsoft Authenticator is a meaningful improvement. FIDO2 security keys and certificate-based authentication are stronger still.
A practical SMB approach is:
1. Require MFA for all users.
2. Require stronger MFA for administrators.
3. Disable legacy authentication.
4. Prefer Microsoft Authenticator with number matching.
5. Use FIDO2 keys for high-risk users such as finance, executives, and IT admins.
### Recommended authentication method policy
In the Entra admin center, review Protection > Authentication methods. Consider the following baseline:
– Enable Microsoft Authenticator for all users
– Enable number matching and application context
– Disable SMS for administrators
– Allow FIDO2 security keys for privileged and high-risk users
– Disable unused methods such as voice call unless there is a documented need
– Require users to register security info before access is needed during travel or an incident
For SMBs with cyber insurance requirements, MFA enforcement is often specifically requested for email, remote access, administrative access, and cloud services. Entra ID is usually the best place to prove and enforce those requirements.
## Block legacy authentication
Legacy authentication protocols, such as basic authentication for older mail clients, do not support modern MFA flows. If allowed, they can provide a path around your MFA policy. Microsoft has disabled basic authentication for many Exchange Online protocols, but environments should still explicitly block legacy authentication where possible.
Create a Conditional Access policy with these characteristics:
– Users: all users
– Cloud apps: all cloud apps
– Conditions: client apps includes legacy authentication clients
– Access control: block access
– Exclusions: emergency access accounts only
Before enforcing, review sign-in logs for legacy authentication usage. If an old scanner, copier, or application is still using SMTP AUTH, replace it with a supported relay design or a dedicated, tightly controlled method. Do not leave legacy authentication open tenant-wide because one device is outdated.
## Build Conditional Access policies in layers
Conditional Access is where Entra ID becomes a practical Zero Trust control plane. The key is to avoid one giant policy that tries to do everything. Use clear, layered policies with descriptive names and limited exclusions.
A reasonable SMB baseline includes:
1. Block legacy authentication.
2. Require MFA for all users.
3. Require phishing-resistant MFA or compliant device for admins.
4. Block access from high-risk countries where the business does not operate.
5. Require approved client apps or app protection policies for mobile access.
6. Require MFA for risky sign-ins where Entra ID Protection is licensed.
7. Restrict administrative portals to trusted locations or stronger authentication.
### Example Conditional Access policy naming
Use names that explain intent and enforcement state:
“`text
CA001 – Block legacy authentication – Enabled
CA002 – Require MFA for all users – Enabled
CA003 – Require strong auth for administrators – Report-only
CA004 – Block non-business geographies – Enabled
CA005 – Require compliant device for admin portals – Report-only
“`
Report-only mode is valuable. It lets you see impact before enforcement. However, report-only is not security. Policies should move to enabled after testing and documented exceptions.
### Avoid dangerous exclusions
Common Conditional Access mistakes include excluding all executives, all service accounts, or all mobile users. Exclusions should be specific, documented, and reviewed. If a user cannot satisfy a policy, fix the root cause rather than creating a permanent bypass.
For example, if the CEO travels frequently, do not exclude the CEO from MFA or location controls. Instead, use stronger MFA methods, device compliance, and risk-based sign-in controls.
## Reduce standing administrative privilege
Administrative accounts are high-value targets. In many SMB tenants, the same account used for daily email also has Global Administrator rights. This is convenient, but it increases the blast radius of phishing and malware.
A better design is:
– Separate daily user accounts from admin accounts
– Assign the least privileged admin role needed
– Use Privileged Identity Management where licensing allows
– Require strong MFA for every privileged role
– Review role assignments monthly or quarterly
Instead of Global Administrator, consider narrower roles such as Exchange Administrator, SharePoint Administrator, Teams Administrator, Helpdesk Administrator, User Administrator, or Security Reader. Fewer global admins means fewer opportunities for tenant-wide compromise.
### Example: find users with assigned privileged roles
“`powershell
Connect-MgGraph -Scopes ‘RoleManagement.Read.Directory’,’Directory.Read.All’,’User.Read.All’
Get-MgDirectoryRole | ForEach-Object {
$role = $_
Get-MgDirectoryRoleMember -DirectoryRoleId $role.Id | ForEach-Object {
$user = Get-MgUser -UserId $_.Id -ErrorAction SilentlyContinue
if ($user) {
[PSCustomObject]@{
Role = $role.DisplayName
User = $user.UserPrincipalName
}
}
}
} | Sort-Object Role, User | Format-Table -AutoSize
“`
Export this list and review it with business leadership. The right question is not whether someone is trusted. The question is whether the business needs that level of standing access.
## Control guest users and external collaboration
Guest access is useful for clients, vendors, consultants, and partners. It is also easy to forget. Over time, tenants accumulate guest accounts that still have access to Teams, SharePoint sites, and documents long after the project ends.
Recommended guest controls include:
– Require MFA for guest users
– Limit who can invite guests
– Configure guest access reviews for sensitive groups and Teams
– Remove stale guests after inactivity
– Use sensitivity labels and sharing controls for confidential data
– Avoid anonymous links for sensitive files
If your business handles regulated data, guest access should be part of your compliance review. HIPAA, PCI, and contractual security obligations often depend on knowing who can access sensitive information and why.
## Review enterprise applications and consent
OAuth app consent abuse is a common cloud attack path. A user may be tricked into granting an application permission to read mail, access files, or maintain persistent access without the attacker needing the password again.
Review Enterprise applications in Entra ID and look for:
– Apps with high-privilege permissions
– Apps no one recognizes
– Apps with broad user consent
– Unused apps with active permissions
– Applications created by former employees or vendors
A secure baseline should restrict user consent to verified publishers and low-risk permissions, or require admin approval for consent requests. This adds a small amount of administrative overhead, but it prevents users from accidentally granting dangerous access.
### Practical configuration guidance
In Entra ID, review Enterprise applications > Consent and permissions. For many SMBs, a reasonable configuration is:
– Do not allow user consent for unverified publishers
– Allow user consent only for selected low-risk permissions
– Enable admin consent workflow
– Assign reviewers who understand the business application need
– Document approved applications and owners
This is especially important for finance, legal, healthcare, and professional services firms where mailbox and file access can contain highly sensitive data.
## Turn on logging and retain enough history
Security controls are incomplete without logs. When an incident occurs, you need to answer basic questions quickly: Who signed in? From where? Which application was used? Was MFA satisfied? Were mailbox rules changed? Was data accessed or shared externally?
At minimum, monitor:
– Entra ID sign-in logs
– Audit logs
– Risky users and risky sign-ins
– Microsoft 365 unified audit log
– Exchange mailbox forwarding and inbox rules
– Admin role changes
– Conditional Access policy changes
– Enterprise application consent events
Default log retention may not be enough for investigations, insurance claims, or compliance needs. Many SMBs benefit from forwarding logs to Microsoft Sentinel, a managed SIEM, or another centralized logging platform.
### Example: suspicious sign-ins query
“`kusto
SigninLogs
| where TimeGenerated > ago(7d)
| where ResultType != 0 or RiskLevelAggregated in (‘medium’,’high’)
| project TimeGenerated, UserPrincipalName, AppDisplayName, IPAddress, Location, RiskLevelAggregated, ResultDescription
| order by TimeGenerated desc
“`
### Example: mailbox forwarding review with Exchange Online PowerShell
“`powershell
Connect-ExchangeOnline
Get-Mailbox -ResultSize Unlimited | Where-Object {
$_.ForwardingSmtpAddress -or $_.ForwardingAddress
} | Select-Object DisplayName, UserPrincipalName, ForwardingSmtpAddress, ForwardingAddress
Get-InboxRule -Mailbox [email protected] | Where-Object {
$_.ForwardTo -or $_.RedirectTo -or $_.ForwardAsAttachmentTo
} | Select-Object Name, Enabled, ForwardTo, RedirectTo, ForwardAsAttachmentTo
“`
Mailbox forwarding is not always malicious, but unexpected forwarding rules are common after business email compromise. Review them regularly.
## Secure device access, not just user access
Identity and endpoint security are connected. If a user signs in from an unmanaged personal laptop infected with malware, MFA alone may not protect the business. Device compliance gives Conditional Access more context.
For organizations using Microsoft Intune, consider policies that require:
– Supported operating system versions
– Disk encryption such as BitLocker or FileVault
– Endpoint protection enabled
– Firewall enabled
– No jailbroken or rooted mobile devices
– Screen lock and password policies
– Defender for Endpoint risk level below a defined threshold
Then use Conditional Access to require compliant devices for sensitive apps or administrative portals. For some SMBs, requiring compliant devices for all Microsoft 365 access may be realistic. For others, start with admins, finance, and regulated data workflows.
## Plan for service accounts and automation
Service accounts are often the reason security baselines get weakened. A backup system, scanner, ERP integration, or reporting script may rely on a password that never changes and cannot complete MFA.
Modernize service access where possible:
– Use managed identities for Azure resources
– Use certificate-based app authentication for automation
– Use application permissions only when required
– Store secrets in a vault, not in scripts
– Assign the least privilege required
– Monitor sign-ins and token usage
– Avoid shared user accounts for services
For PowerShell automation against Microsoft Graph, certificate-based authentication is often preferable to storing a username and password.
### Example: app-only connection pattern
“`powershell
Connect-MgGraph -ClientId ‘00000000-0000-0000-0000-000000000000’ -TenantId ‘11111111-1111-1111-1111-111111111111’ -CertificateThumbprint ‘ABCDEF1234567890ABCDEF1234567890ABCDEF12’
“`
This still requires careful permission management. App-only permissions can be powerful, so review them like administrator accounts.
## Create an operational review schedule
A security baseline is not a one-time project. Businesses change. Employees leave. Vendors come and go. Applications are added. Attack techniques evolve. The baseline needs an operating rhythm.
A practical schedule for SMBs:
### Weekly
– Review risky sign-ins and risky users
– Review admin account sign-ins
– Check alerts for impossible travel or unfamiliar locations
– Investigate failed MFA spikes
### Monthly
– Review privileged role assignments
– Review guest users added during the month
– Check Conditional Access policy changes
– Review mailbox forwarding and suspicious inbox rules
– Confirm backup admin and emergency access account documentation
### Quarterly
– Test break-glass account access under controlled conditions
– Review enterprise applications and consent grants
– Validate cyber insurance identity security requirements
– Review device compliance reports
– Confirm offboarding process removes access completely
### Annually
– Review the overall identity architecture
– Update incident response procedures
– Validate logging retention and investigation workflows
– Conduct tabletop exercises for account compromise and ransomware scenarios
This schedule is where a managed IT provider can add significant value. The technology matters, but consistent execution is what keeps a tenant secure.
## Common deployment mistakes to avoid
Even well-intentioned teams can create risk while improving security. Watch for these common issues:
– Enabling strict policies without report-only testing
– Excluding too many users from MFA or Conditional Access
– Leaving legacy authentication enabled for old devices
– Using daily email accounts as global admins
– Forgetting to monitor break-glass accounts
– Allowing unrestricted user consent to third-party apps
– Not retaining logs long enough for investigations
– Treating guest users as harmless
– Failing to document exceptions
– Assuming Microsoft 365 security is fully automatic
Microsoft provides strong tools, but the tenant owner is responsible for configuration, monitoring, and governance.
## A practical SMB Entra ID baseline checklist
Use this checklist as a starting point for a real deployment:
– Create two cloud-only emergency access accounts
– Enforce MFA for all users
– Require stronger authentication for administrators
– Block legacy authentication
– Separate admin accounts from daily user accounts
– Reduce Global Administrator assignments
– Configure Conditional Access in clear layers
– Use report-only mode before enforcement
– Restrict risky geographies when appropriate
– Require MFA for guest users
– Review guest access regularly
– Restrict user consent and enable admin consent workflow
– Review enterprise applications monthly or quarterly
– Enable and review Microsoft 365 audit logging
– Monitor mailbox forwarding and inbox rules
– Use device compliance for sensitive access
– Modernize service accounts and automation authentication
– Document exceptions and review them regularly
Not every business needs the same policy set. A five-person design firm, a medical practice, and a manufacturing company with remote plants will have different requirements. The baseline should be adapted to business risk, compliance obligations, and operational reality.
## When to involve a managed IT provider
Many SMBs can enable basic MFA themselves. The challenge is designing policies that do not break business workflows while still providing meaningful protection. Conditional Access, device compliance, app consent, logging, and incident response require experience across identity, endpoints, networking, and business operations.
A qualified managed IT provider can help by:
– Auditing the current tenant configuration
– Designing a phased Conditional Access rollout
– Aligning controls with cyber insurance requirements
– Implementing secure admin and break-glass processes
– Integrating Entra ID logs with monitoring tools
– Hardening Microsoft 365, endpoints, and email security together
– Providing ongoing reviews and incident support
The best provider will not simply turn on a template and walk away. They will document decisions, test impact, train users, and revisit the environment regularly.
## Summary and key takeaways
Microsoft Entra ID is now a critical security boundary for SMBs. If an attacker controls identity, they can often control email, files, applications, and administrative access. A practical Entra ID security baseline reduces that risk without making the business unusable.
Key takeaways:
– Treat Entra ID as core security infrastructure, not just a login directory.
– Enforce MFA for everyone and stronger authentication for administrators.
– Block legacy authentication so attackers cannot bypass modern controls.
– Use layered Conditional Access policies with careful testing and minimal exclusions.
– Separate administrative accounts and reduce standing privilege.
– Monitor guest users, enterprise applications, mailbox forwarding, and risky sign-ins.
– Retain logs long enough to support investigations, compliance, and insurance needs.
– Review the baseline on a schedule because identity security is an ongoing process.
For SMBs, the right Microsoft Entra ID configuration can prevent common account compromise scenarios and provide the visibility needed to respond quickly when something suspicious happens. Computer Butler helps businesses design, deploy, and manage secure Microsoft 365 and Entra ID environments that match real-world operations, compliance needs, and budget constraints.
