Microsoft Secure Score – A Guide to Improve

“How secure is our IT?” It’s a simple question, yet many business owners struggle to answer it confidently—especially when cyber insurance forms or potential clients demand a clear metric. One crucial measure for organizations using Microsoft 365 is the Microsoft Secure Score. This security analytics tool assesses your organization’s security posture across Microsoft 365 and assigns a numerical score reflecting how well your environment aligns with recommended security practices. A higher Secure Score indicates more of the recommended security actions have been implemented, thus a lower identified risk level. This score has real-world implications: insurers might base your premiums on it, and prospective customers increasingly inquire about it before doing business. In fact, participating cyber insurers now use Secure Score to offer posture-based rates to SMBs. Executives and partners may also view it as a benchmark of trust and security maturity.

General Secure Score

How Secure Score is Calculated (2025): Microsoft Secure Score assigns points to each recommended security action (up to 10 points each) and tallies them as a fraction of the total possible points for your environment. Most actions are scored in a binary fashion – you get full points when the action is fully implemented, or partial points if only some users/devices are covered. For example, enabling multifactor authentication for all users might be worth 10 points; if you’ve protected 50 of 100 users, you earn 5 points (50% of 10). The score updates in near real time as you implement improvements. It covers identities, devices, apps, data, and more, including integrations for third-party solutions (e.g. Okta, Salesforce) so that mitigating controls outside of Microsoft can still count toward your score. Essentially, Secure Score measures how many recommended security controls you have adopted relative to the total, often displayed as a percentage. While 100% sounds ideal, it’s rarely practical – not every recommendation fits every environment, and some may be intentionally accepted risks. Many businesses start below 60% and need improvement. A score between 60% and 80% indicates good security practices, while anything above 80% is excellent and comparatively rare in practice.

Secure Score and Cyber Insurance: A strong Secure Score can directly benefit your organization financially. Insurers view a high score as a sign of lower breach risk and may offer lower cyber insurance premiums to organizations with stronger security postures. In 2023, Microsoft even partnered with cyber insurers to enable premium credits for high Secure Scores. Think of it like a safe driving discount for cybersecurity – companies with robust security (as reflected by Secure Score) are starting to “pay less for cyber insurance, much like how safe drivers get lower car insurance rates”. Conversely, a poor score could increase your premiums or even make it harder to obtain coverage. Beyond insurance, Secure Score is becoming a due diligence item; enterprises and regulators are beginning to ask for minimum security score thresholds in supply chain contracts and compliance audits.

Does a High Secure Score Mean Fewer Breaches? In general, yes – a higher Secure Score correlates with a lower risk of incidents. Secure Score embodies adherence to best practices (like MFA, up-to-date patching, etc.) that make attacks harder. Microsoft has reported that organizations with Secure Score above 80% experienced 67% fewer security incidents compared to those with lower scores. Similarly, having more of the recommended controls in place means fewer “easy” gaps for attackers – for example, ensuring all users do MFA and blocking legacy logins drastically cuts the odds of account compromise. However, it’s important to remember Secure Score is not a guarantee of invulnerability. It’s possible to have a high score and still be breached via a novel attack or misconfiguration not measured by Secure Score. The score is best used as a continuous improvement metric. Microsoft positions Secure Score as a way to report on and improve your security posture, not an absolute predictor. In practice, organizations treat achieving a certain percentage as a KPI and find that pushing the score higher does drive meaningful hardening of defenses. In short: a higher Secure Score doesn’t guarantee zero breaches, but it strongly correlates with a reduced likelihood of successful attacks, acting as a measurable proxy for good security hygiene.

What’s a “Good” Secure Score? Because the total points vary by environment (depending on which Microsoft solutions you have), many organizations focus on the percentage. As noted, 60-80% is a common “good” range – it shows you’ve implemented a majority of best practices. Above 80% is excellent and often only achieved by mature organizations that have addressed nearly all recommendations. Industry averages can vary; one Microsoft partner noted many clients operate around 70% and continuously strive to maintain or improve that level. If your score is below 50-60%, it’s a clear sign you should prioritize improvements. Also, track your Secure Score over time – the goal is to see an upward trend or sustained high values, indicating you are keeping up as new recommendations are added. Finally, remember to balance security with usability; not every action fits every business, and Secure Score allows marking certain controls as “risk accepted” if you choose not to implement them. Use the score as a guide, not an absolute mandate.

User Protection

Protecting user accounts is often the top priority, as compromised identities are a gateway to your data. Microsoft Entra ID (formerly Azure AD) provides powerful controls to harden user authentication and access. Below are best practices for user protection in Microsoft 365:

Conditional Access Best Practices (Microsoft Entra ID)

Conditional Access (CA) is Microsoft’s policy engine for enforcing Zero Trust controls on user sign-ins. It allows you to require certain conditions (like MFA, compliant device, trusted location, etc.) before granting access to apps. Best practices for CA policies in 2025 include the following foundational policies:

• Block Legacy Authentication: Older protocols (IMAP, POP, SMTP, etc.) that don’t support MFA should be universally blocked. Microsoft reports that over 99% of password-spray attacks target legacy auth protocols. By creating a CA policy to block all legacy authentication attempts (for all users, all apps), you shut the door on a huge class of attacks where attackers leverage stolen passwords without MFA. (Implement this in report-only mode first to ensure no needed apps are using legacy auth.)
• Require MFA for All Users: Don’t just MFA protect admins – enforce multi-factor authentication for every user account, either at every login or at least once per session/trusted device. Modern authenticator apps and prompts make MFA user-friendly, and it dramatically reduces the chance of account takeover (Microsoft observes that accounts are 99.9% less likely to be compromised with MFA in place). In Conditional Access, create a policy for All users on All cloud apps requiring MFA on sign-in. At a minimum, require MFA for privileged roles if you roll out gradually. Combined with blocking legacy auth, this ensures stolen passwords alone can’t breach your tenant.
• Require MFA for Risky Sign-ins: Microsoft Entra ID’s Identity Protection can detect atypical or high-risk login attempts (impossible travel, unfamiliar locations, known breached credentials, etc.). Leverage this by having a CA policy that, for any sign-in flagged as medium/high risk, forces an MFA challenge or blocks access. This adds an adaptive layer of security – even a user who normally isn’t prompted for MFA might be if their login is deemed suspicious. (Identity Protection requires Azure AD P2 or equivalent; if available, also consider user risk policies to force password resets for compromised accounts.)
• Limit Access to Trusted Devices: For sensitive applications or data, enforce that only compliant or domain-joined devices can access them. This is done via CA policy integrating with Intune device compliance. For example, require work devices (that meet your security standards) for accessing financial or HR systems. This protects against data access from unmanaged, potentially insecure personal devices. Many organizations start with a policy to block access from unmanaged devices to key apps or to all apps except Office web (depending on their BYOD strategy).
• Implement Session Controls: CA can work with Defender for Cloud Apps to enforce session policies (like limiting download of files for unmanaged devices via browser). While a more advanced scenario, it’s a best practice to consider for high-risk scenarios – e.g. allow web-only access with limited functionality on BYOD devices. Also, enable Continuous Access Evaluation (CAE) so that if a user’s risk state changes (account disabled, token stolen, etc.), session tokens are revoked faster.

When deploying Conditional Access, always exclude at least one break-glass global admin account from all policies (for emergency access). Use CA’s “Report-only” mode and the What-If tool to test new policies before enforcing – this prevents accidentally locking out users or admins due to policy misconfigurations. By following these CA best practices, you establish strong access baseline rules: no legacy auth, MFA everywhere, dynamic risk response, and device trust requirements. These measures significantly harden user authentication in your tenant.

Deploying MFA Across Hybrid Environments

In a hybrid identity environment (with on-prem Active Directory synced to Entra ID), deploying MFA requires a few considerations to cover both cloud and on-prem access:

• Sync Identities to Azure AD: Ensure you have Azure AD Connect set up to synchronize your on-prem AD accounts to Entra ID. This allows cloud MFA policies to apply to your users. Password Hash Sync or Pass-through Authentication with Seamless SSO is recommended so that Azure AD can directly handle user sign-ins and MFA for those accounts.
• Use Conditional Access for Cloud Apps: As noted above, the simplest and most effective approach is to use Azure AD Conditional Access to require MFA for user logins to cloud resources. For hybrid users, once they authenticate via Azure AD, the CA policies will prompt for MFA as needed – there is no difference in experience whether their source of authority is on-prem or cloud. With Microsoft 365 Business Premium (which includes Azure AD P1), you already have the needed licensing for MFA via CA.
• Enable Modern Authentication On-Premises: If you still have on-premises applications (like older versions of Exchange/SharePoint or VPNs) that users access, consider integrating them with Azure AD or enabling federation to apply MFA. For example, Azure AD App Proxy can publish on-prem web apps and enforce Azure AD MFA for them. For VPNs, Microsoft offers the NPS extension for Azure MFA to enforce MFA on RADIUS connections. Additionally, encourage use of Azure AD MFA for Windows sign-in via Windows Hello for Business, which uses MFA-backed credentials for workstation login. This extends strong authentication to the desktop logon.
• Educate and Roll Out in Phases: In hybrid orgs, some users might be authenticating directly to on-prem AD for certain services. Provide guidance that they may need to perform MFA on their mobile device when accessing cloud apps. It’s wise to roll out MFA in phases (e.g. pilot with IT team, then execs/admins, then all users) and leverage Azure AD features like SSPR combined registration so users register their Authenticator app or phone in advance. Microsoft’s deployment guides suggest enabling MFA for all users via CA, then disabling any legacy per-user MFA settings for a smoother experience.
• On-Prem MFA Server (Deprecated): Microsoft had an old on-premises MFA Server for AD – this is now deprecated and not recommended for new deployments. Instead, use cloud-based Azure MFA even for hybrid scenarios. Almost all use cases (VPN, RDP, on-prem web apps) can be integrated with Azure MFA.

In summary, deploying MFA in a hybrid environment means syncing your identities to the cloud and using Azure AD’s MFA capabilities for all services possible. By requiring MFA for O365, Exchange Online, VPN, and any critical on-prem apps (via integration), you ensure that whether users access resources on-prem or in the cloud, a second authentication factor is always needed. This unified approach closes gaps that attackers might try to exploit on less protected legacy systems.

Securing Administrative Roles with PIM

Highly privileged accounts (Global Administrators, Exchange Admins, etc.) are a top target for attackers, so securing them is paramount. Microsoft Entra Privileged Identity Management (PIM) is a feature (in Azure AD P2 or EMS E5) that can greatly reduce the risk by enabling just-in-time admin access. Best practices for using PIM to secure admin roles:

• Minimize Permanent Privilege: Use PIM to make admin role assignments “eligible” rather than permanent. This means an admin has no active privileges until they activate their role on demand. Microsoft recommends having zero users with standing admin roles (except two emergency break-glass accounts) and having all other admins go through PIM for time-limited access. For example, instead of 5 Global Admins 24/7, you might have 2 emergency accounts (unused normally) and everyone else (e.g. IT managers) set as eligible for Global Admin. This sharply limits the window in which a compromised admin account can do damage.
• Require MFA and Approval for Role Activation: PIM allows you to configure that when an admin needs to activate (say, become Exchange Administrator), they must perform MFA and possibly get approval from a designated approver. Requiring MFA on activation adds an extra layer in case that user’s credentials were stolen. Approval workflows ensure at least two people are aware of and consent to the elevation. These measures prevent stealthy admin abuse – an attacker would face MFA prompts and oversight.
• Time-Bound and Just-Enough Access: With PIM, you specify how long a role activation lasts (e.g. 1 hour or 4 hours). After that, the role is removed automatically. This limits the duration of high privilege. PIM also facilitates just-in-time and just-enough access – you can make custom roles or use lower-privileged built-ins so that admins activate only what they need for a task. For instance, use a lesser admin role (like Teams Admin or User Admin) for most tasks and only elevate to Global Admin for rare operations. This adheres to the principle of least privilege.
• Activity Visibility and Alerts: PIM provides audit logs and can send notifications when roles are activated. Set up alerts for unusual PIM events – e.g. if someone activates Global Admin at 2 AM, your security team should know. PIM can also notify you if new permanent admin assignments are created outside of PIM. This oversight helps catch illicit elevation of privilege.
• Access Reviews: Over time, organizations can accumulate “role creep”. PIM integrates with access reviews – you can schedule periodic reviews of admin role assignments to ensure those eligible still need it. Remove users who no longer require certain roles. This cleans up excessive privilege and ensures compliance (especially helpful for demonstrating control of admin access in audits).

Using PIM, one company reduced its number of always-active Global Admins to just two break-glass accounts. All other IT staff must activate roles through PIM, with MFA and managerial approval. This significantly lowered the risk of an attacker gaining unchecked admin access. In summary, PIM transforms admin roles from standing access to on-demand access. By doing so, it mitigates insider risk and limits the blast radius if an admin account is compromised. Every Microsoft 365 organization with high-privilege accounts should leverage PIM or similar concepts to secure those critical roles.

Email Protection

Email remains a primary vector for cyberattacks (phishing, malware) as well as accidental data leakage. Microsoft 365 provides built-in email security through Exchange Online Protection and Microsoft Defender for Office 365. Here’s how to strengthen email protection:

Configuring Microsoft Defender for Office 365 (Step-by-Step)

Microsoft Defender for Office 365 (Plan 1 is included in M365 Business Premium) adds advanced threat protection for email and collaboration. To configure it for optimal security, follow these steps:

1. Enable Anti-Phishing Policies: In the Microsoft 365 Defender portal, configure anti-phishing policies to protect against impersonation and spoofing. Use the default Standard Preset Security Policy or create a custom policy. Key settings include enabling user impersonation protection (specify protected VIP users like your CEO so that emails spoofing their name are flagged) and domain impersonation protection (so attackers can’t use look-alike domains to fool your users). Also turn on Mailbox Intelligence features – these use machine learning to detect emails that don’t match a recipient’s typical senders. Anti-phishing policies will then automatically junk or quarantine suspicious impersonation attempts and can provide warning tooltips to users.
2. Configure Anti-Malware Policies: Ensure anti-malware is enabled for all inbound and outbound email. Defender for Office 365 scans all attachments for viruses and known malware. In policies, you can enable features like Zero-Hour Auto Purge (ZAP) which will remove emails from inboxes if malware is detected after delivery. Also consider enabling File Type Blocking if you want to reject messages with certain file types often used for malware (e.g. .exe, .js files).
3. Enable Safe Attachments (Sandboxing): Safe Attachments is an advanced feature where email attachments are detonated in a virtual sandbox. Turn on Safe Attachments for your users – ideally in Block mode (which drops malicious attachments entirely) or Replace mode (replaces with a message if malicious). This can catch zero-day malware that signatures don’t yet recognize. Safe Attachments may introduce a slight delay in email delivery for scanning, but it significantly improves protection.
4. Enable Safe Links: Safe Links protection will URL-wrap links in emails and Office docs, scanning them at the time of click. Configure a Safe Links policy to on for all users, with options to prevent users from clicking through to original URL if it’s malicious. This helps protect against phishing links or delayed “weaponized” URLs. Microsoft’s threat intelligence will block known bad sites, and unknown links can be scanned in real-time when clicked.
5. Set Up Anti-Spam and Spoofing Protections: Defender includes spam filtering by default, but review the anti-spam policy to adjust thresholds. Enable spoof intelligence so that if an external sender tries to spoof your domain or send as someone in your org, the system will junk/quarantine it. Also turn on unauthenticated sender tagging, which marks emails that fail SPF/DKIM/DMARC. Microsoft’s guidance is to utilize DMARC (see below) to help identify and reject spoofed emails.
6. Use Preset Security Templates: Microsoft provides Preset Security Policies (“Standard” and “Strict”) which bundle all the above in recommended configurations. As a quick start, apply the Standard Preset to all users – it will turn on Defender for Office 365 protections at a balanced level. High-risk users or those wanting maximum protection can be put on the Strict Preset for even more aggressive filtering. Preset policies simplify deployment by using best-practice settings curated by Microsoft.
7. User Training & Simulation: Turn on the Attack Simulation Training (if available) to run phishing simulation campaigns. While not a configuration of Defender per se, educated users are part of email defense. Additionally, use Report Message/Phish add-ins so users can report suspicious emails – these reports go to Microsoft and your security team for further analysis.

By systematically configuring these features, you create a layered filtering stack: connection filtering at the edge, sender intelligence with SPF/DKIM/DMARC and spoof guard, content filtering via Safe Attachments & Safe Links, and user awareness. Microsoft’s step-by-step setup guides emphasize starting with these core protections to get quick wins securing Office 365. Each improvement (MFA, anti-phish, etc.) not only raises your Secure Score but genuinely strengthens your email security posture.

Impacts of DMARC on Email Deliverability

DMARC (Domain-based Message Authentication, Reporting and Conformance) is an email authentication policy that builds on SPF and DKIM. In terms of deliverability, DMARC can have both positive and negative impacts:

• Preventing Spoofed Emails: When you publish a DMARC policy (especially p=reject or p=quarantine), recipient mail servers will check that emails claiming to be from your domain pass SPF/DKIM and align with your domain. This greatly reduces successful spoofing of your domain in phishing attacks. As a result, it protects your brand and ensures legitimate emails aren’t overshadowed by spams pretending to be you. Over time this can boost your domain’s sender reputation – some studies find organizations see a measurable increase in their email deliverability (to inbox instead of spam) after enforcing DMARC, because receiving servers trust their mail more.
• Effect on Outbound Mail: If misconfigured, DMARC can cause your legitimate emails to be rejected. For example, if you set p=reject and an email from your domain fails DMARC (maybe a third-party sender wasn’t authorized in your SPF, or a forwarded email broke DKIM), the recipient will likely refuse delivery. p=reject has the highest impact on deliverability – it can outright block emails that don’t pass authentication. A p=quarantine policy is a bit softer: failing messages might land in spam folder instead of being rejected. p=none has no impact on delivery (it’s just monitoring).
• Getting it Right: To avoid hurting your own deliverability, you must carefully implement DMARC. This means: ensure all your email sources (marketing services, CRM, etc.) either send DKIM-signed emails with your domain or are included in your SPF. Many companies roll out DMARC gradually – start with p=none to gather reports, move to p=quarantine once SPF/DKIM are fully in place, and finally p=reject when confident. You can also use DMARC’s % tag to only partially enforce during rollout. Gradual enforcement minimizes false positives while still reaping benefits.
• Improved Deliverability with Enforcement: Interestingly, once fully and correctly implemented, DMARC enforcement can improve your overall deliverability. It ensures that only authenticated mail claiming to be you is accepted, which means spam using your domain gets blocked. This can raise mailbox providers’ trust in emails actually from you. Some organizations have reported a small but significant uplift (e.g. a 10% boost in marketing email deliverability) after moving to DMARC reject, as noted by industry analyses.

In summary, DMARC helps email deliverability if done properly: it stops scammers from using your domain (so your mails aren’t mistaken for spam), but if you go to a strict policy without proper setup, it could interfere with legitimate mail delivery. Always use DMARC in conjunction with solid SPF/DKIM records and monitor the DMARC reports to fix any sources that fail. With Microsoft 365, enabling DKIM signing on your domains and publishing a DMARC record (even start with p=none for reporting) is a best practice to bolster email security and deliverability.

Microsoft 365 Email Protection vs Third-Party Vendors

Many organizations wonder if the built-in Microsoft 365 email security is enough, or if they need a third-party Secure Email Gateway (SEG) like Proofpoint, Mimecast, or Barracuda. For small and midsize enterprises (SMEs) using Business Premium or E3/E5, Microsoft’s native protections have significantly improved and often suffice. A few points of comparison:

• Integration: Microsoft Defender for Office 365 is tightly integrated with the M365 ecosystem. It works within Exchange Online, meaning no complex mail flow rerouting is needed. This integration allows unified threat telemetry – signals from email, endpoint, identity all feed into Microsoft’s security graph. Third-party vendors typically act as an external gateway where you change MX records to route mail through them. This adds an extra hop and can introduce complexity in configuration. However, those vendors are platform-agnostic and can protect multiple email platforms.
• Effectiveness: Independent tests have shown Microsoft’s filtering to be on par with leading vendors for broad-spectrum threats (spam, known malware). Microsoft has massive data feeds (billions of emails daily) and invests heavily in AI for threat detection. Third-party vendors often excel in certain niches or targeted threats – for example, a vendor might have specialized phishing detection that catches very tailored spear-phish attacks slightly better, or offer more customizable DLP for email. Out of the box, some admins report needing to fine-tune Microsoft’s policies to reduce false positives/negatives, whereas a vendor’s service might come somewhat optimized. But Microsoft’s preset policies and continuous improvements have closed the gap substantially.
• Features: A third-party SEG might offer extra features like advanced attachment sandboxing, impersonation detection, and detailed threat dashboards – but Microsoft now offers those too in Defender for Office 365 Plan 2. For instance, via Microsoft’s portal you get attack campaign views, user submission processing, and automation playbooks, which historically might have required a third-party. One differentiator: if you want domain segregation or encryption key control, certain vendors offer that. Microsoft’s solution covers the major bases: anti-spam, anti-phish, sandbox, safe links, auto-remediation, etc., all included in the licensing you may already have.
• Cost: Using Microsoft’s built-in security that comes with your license is cost-effective. Third-party solutions are an additional expense (often charged per user/mailbox per year). Many SMEs choose to maximize the security features they already pay for in M365 before considering an add-on. In fact, many have decided to replace other email security gateways with Microsoft Defender to save costs. A consulting firm BDO noted that if you already use M365 for email, using Defender for Office 365 can replace redundant services like Proofpoint or Mimecast and achieve cost savings.
• Management: With Microsoft, security administration occurs in the Defender or Purview portals, alongside your other security management. Third-party systems have their own portal. This can be a pro or con: a dedicated vendor portal might have more granular controls or reports for email-specific issues; but it’s another interface and may not tie into Azure AD logs or Microsoft Secure Score easily. Microsoft’s admin experience has unified dashboards (and even a Security Score contribution from email config).

Case-by-case decision: If your organization faces very sophisticated targeted attacks or has regulatory needs that require a specific gateway feature, a third-party might still be worthwhile. For example, some financial firms layer a Proofpoint on top of Exchange for additional assurance or specific encryption workflows. However, for most SMEs and even many enterprises, Microsoft 365’s native email security, when properly configured, provides comprehensive protection. It benefits from Microsoft’s rapid response to new threats (like if a new phishing campaign emerges, Microsoft can update detections across all tenants quickly) and simplifies your architecture.

In summary, the gap between Microsoft and third-party email security has narrowed greatly. Many businesses are consolidating on Microsoft for an integrated, cost-effective solution. The key is to fully utilize what’s available (as described in the configuration steps above). A layered approach can also be considered – e.g. use Microsoft as primary filter and a lightweight third-party for additional phishing training or backup scanning. But running two full email filters is often unnecessary. For SMEs with Business Premium: focus on tuning Microsoft Defender for Office 365; it is likely to meet your needs and improve your Secure Score, while saving the overhead of an external gateway.

Device Protection

With a workforce often spread across offices and home, protecting devices (both company-issued and BYOD) is vital. Microsoft 365 Business Premium (or Enterprise with Intune) offers tools to ensure devices accessing corporate data are secure. Key strategies include enforcing compliance policies, deploying endpoint protection like Defender and BitLocker, and managing BYOD devices with app protections.

Enforce Device Compliance with Intune

Microsoft Intune (Endpoint Manager) allows you to define device compliance policies – a set of rules that devices must meet to be deemed “compliant” and thus allowed access to company resources. Setting up compliance policies ensures baseline security on all devices. Best practices:

• Define Compliance Requirements: Common settings include requiring a minimum OS version (to avoid unpatched old systems), requiring the device be encrypted (device encryption/BitLocker on Windows, FileVault on Mac, etc.), requiring a password/PIN of a certain complexity, and blocking jailbroken or rooted devices. For example, you might require Windows 10 or above with BitLocker enabled and no administrative unlock, or for mobile require Android devices not be rooted. These policies are configurable per platform (iOS, Android, Windows, etc.).
• Compliance Actions: If a device falls out of compliance (say a user disables their PIN or their OS is out of date), Intune can take actions. One powerful action is integration with Conditional Access: you can have Azure AD block the device from accessing email/SharePoint, etc., if not compliant. This is how you enforce “no access from devices that don’t meet our standards.” Additionally, Intune can send the user a notification email or mark the device for remediation. Many SMEs choose to simply block noncompliant devices from all Office 365 apps using a Conditional Access policy that requires device compliance.
• Use Scope and Gradual Rollout: You can assign compliance policies to all users or specific groups. It’s wise to pilot with IT devices, then critical user groups, then company-wide. Also configure grace periods if needed – for instance, if a device becomes noncompliant due to missing a patch, give the user X days to fix it before blocking. Intune compliance also has a “Compliant/Not Compliant” flag you can view in the portal or reports, which is useful for inventory of how many devices are meeting requirements.
• Leverage Built-in Profiles: Intune provides baseline templates and recommended settings. For Windows, you might use the Endpoint Security > Security Baselines in Intune to set a broad set of secure configuration (covering Windows settings, Defender AV, firewall, etc.). While not the same as compliance policies, these baselines complement them by configuring devices to be secure by default.

By creating compliance policies and tying them to Conditional Access, you achieve a zero-trust posture: only healthy, managed devices can use corporate apps. For example, if someone’s personal device that isn’t enrolled tries to access Teams, they’ll be blocked. Or if a company laptop falls below compliance (e.g. antivirus off), it can be quarantined. In short, Intune compliance policies make security standards measurable and enforceable across your fleet, greatly reducing risk from compromised or insecure devices.

Deploying Defender for Business and BitLocker at Scale

Microsoft Defender for Business (MDB) is an endpoint security solution included in Business Premium, providing next-gen antivirus and threat detection for Windows, Mac, iOS, Android. Deploying it at scale, along with BitLocker disk encryption, ensures all endpoints are protected against malware and data theft:

• Microsoft Defender for Business Set-Up: In the Microsoft 365 Defender portal, run the Defender for Business setup wizard. This will guide you through onboarding devices. For Intune-managed devices, you can enable Endpoint security policies in Intune that automatically onboard them to Defender for Endpoint (Business). Essentially, Intune can deploy the Defender agent and connect it to the cloud service. If you have devices not in Intune, you can use a local script or Group Policy method to onboard them. Onboard all endpoints – including Windows 10/11 PCs, and consider onboarding mobile devices via the Mobile Threat Defense connectors (if using Android/iOS, though those often rely on apps). The goal is to get every device reporting into the Defender portal so you have visibility. Assign appropriate roles so your IT/security staff can manage alerts in the Defender portal.
• Policies for Defender AV and EDR: Through Intune or the Defender portal, apply default antivirus policies – ensure real-time protection, cloud-delivered protection, and tamper protection (prevents malware from disabling Defender) are enabled on all devices. Configure Attack Surface Reduction (ASR) rules to harden endpoints: for example, block Office macros from the internet, block process creations from Office, etc. Microsoft provides a list of recommended ASR rules. It’s best practice to start them in Audit mode to gauge impact, then move to Block mode for full protection. These rules can thwart common malware techniques. With Defender for Business, you also get automated investigation and response – verify this is turned on, so that if a threat is detected, the system can auto-remediate (isolate the file or kill a process).
• Deploying BitLocker at Scale: Intune makes it straightforward to enforce BitLocker drive encryption on all Windows devices. Use an Endpoint Security > Disk Encryption policy in Intune for Windows 10/11. Set it to require encryption of OS drive and (if needed) fixed data drives. You can configure BitLocker settings such as: enable XTS-AES 128 or 256-bit encryption, allow standard users to enable BitLocker (so non-admins can turn it on during device setup), and backup recovery keys to Azure AD automatically. In fact, Intune can silently enable BitLocker on capable devices. Also enforce pre-boot startup authentication (e.g. TPM required, or TPM+PIN if high security) – this ensures the encryption can’t be bypassed by moving the drive to another machine. The Communication Square guide recommends settings like hide 3rd-party encryption prompts, enable BitLocker on OS and data drives, and turn on key rotation for AAD joined devices (a security feature to rotate recovery keys on use). The result: even if a laptop is lost or stolen, the data remains safe and inaccessible to thieves.
• Monitor and Maintain: In Intune’s reports, watch BitLocker compliance. Ideally 100% of your PCs show as encrypted. Also, from the Defender portal, monitor threat detections and device risk scores. Intune compliance policy can even take into account the device’s risk score from Defender – for example, mark a device noncompliant if Defender reports it as high risk (meaning it’s likely compromised). This ties everything together: a malware-infected device can automatically be cut off from company resources until it’s cleaned (when Defender lowers the risk score).

By deploying Defender for Business and BitLocker at scale, one mid-size firm reported a significant drop in malware incidents. They onboarded all 200 devices to Defender (via Intune onboarding policy) and enforced BitLocker; within weeks, Defender had neutralized a couple of malware files that users unwittingly downloaded, preventing any outbreak. BitLocker gave peace of mind that if any device is misplaced, the data isn’t in the wild. The combination provides both active threat protection and data-at-rest protection. Remember to also secure mobile devices – even though BitLocker isn’t for phones, use device encryption on mobiles (Intune compliance can ensure iOS devices have encryption enabled, Android has it by default on modern versions). Overall, this approach hardens endpoints and aligns with Secure Score recommendations (each of these steps adds to your score).

Managing BYOD Securely with Intune MAM

Not all users will be on company-issued hardware – Bring Your Own Device (BYOD) is common, especially for mobile phones. Microsoft’s solution to secure corporate data on personal devices is Intune App Protection Policies, also known as Mobile Application Management (MAM) without device enrollment. These allow you to protect the apps and data your company owns, without managing the entire personal device.

Key practices for BYOD via Intune MAM:

• Apply App Protection Policies to Office Apps: Intune MAM targets specific apps (e.g. Outlook, Teams, OneDrive mobile apps). You create a policy that applies to “unmanaged” devices (devices not enrolled in Intune). For example, you can require any user accessing company email on the Outlook mobile app to have an App Protection Policy that encrypts the app data, requires a PIN or biometric to open the app, and prevents data from being copied to personal apps. This means if a user is on their own phone, they can use Outlook for work mail, but they cannot copy-paste text from an email into a personal app, cannot save attachments to unapproved locations, and if they leave the company, you can remotely wipe the corporate data in that app without affecting their personal stuff.
• Common MAM Policy Settings: In a typical BYOD app protection policy, you would block “save as” or saving files to unmanaged locations, restrict cut/copy/paste so it only works between other managed apps (e.g. Teams to Outlook is allowed, but Outlook to WhatsApp is blocked), and require a PIN or work account sign-in to access the app each time (or after a timeout). You might also prevent screenshotting of the app on Android. These policies ensure corporate data stays in a silo within the device. For example, if a user tries to copy a Teams message containing a client SSN and paste it into a personal note app, it will simply not paste – the policy “contains” the data within managed apps.
• Conditional Access with “Approved Apps”: To truly enforce BYOD usage of only protected apps, use Conditional Access rules in Azure AD: require that for accessing Exchange Online or Teams, the device must be either compliant or the app used must be an approved client app with App Protection. There is a CA condition “Require approved client app” and “Require app protection policy”. By using these, if a user tries to setup the native iOS Mail app for work email (which is not protected by Intune MAM), the access will be blocked. They’ll be forced to use Outlook, which has the MAM policy applied. This is essential – otherwise a user could bypass MAM by using a different app. Pairing CA with MAM ensures BYOD = using managed apps only.
• Platforms and Scope: Intune MAM without enrollment works on iOS and Android. (For Windows BYOD, there is Windows Information Protection for local files, but it’s less used these days and doesn’t apply to cloud apps the same way – for Windows BYOD, often Azure Virtual Desktop or Windows 365 Cloud PC are used instead of direct local access for sensitive data). So focus on mobile scenarios. Deploy the Company Portal app even if not enrolling, as it helps with user experience of receiving MAM policies. Communicate to users that “We don’t see your personal data or manage your phone; we only protect company app data” – this helps alleviate privacy concerns that come with full MDM.

Using MAM, one company with many contractors allowed them to use their personal iPhones for email and Teams, but with policies: contractors could not save or copy confidential info out of Outlook and after 30 minutes of inactivity the Outlook app required re-authentication with their work account. When a contractor’s engagement ended, IT simply issued a wipe command for app data – the next time the user opened Outlook, the work account was removed (their personal emails or other apps remained intact). This approach greatly reduced incidents of accidental data leaks on BYOD. It also raised their Secure Score by fulfilling the requirement of protecting mobile data with MAM. Essentially, Intune App Protection gives you a lightweight container on BYOD devices, allowing productivity without sacrificing security.

Remember that MAM policies can also apply to managed devices, but you can target them specifically to unmanaged if you want to differentiate. Also, don’t forget PC BYOD – if users access via personal laptops, consider leveraging Azure Virtual Desktop or web-only access to keep data off untrusted machines, or at least use sensitivity labels and DLP (described below) to control what they can do. But for mobile BYOD, Intune MAM is a proven solution that implements Microsoft’s Zero Trust principle of “verify explicitly and least privilege” at the app/data level on personal devices.

Data Protection

Protecting data itself – wherever it resides or travels – is the last but crucial piece. Microsoft Purview (the new name for compliance and information protection suite) provides tools like Sensitivity Labels and Data Loss Prevention (DLP) to prevent unauthorized sharing or leakage of sensitive information. Additionally, understanding real-world use cases of DLP can help illustrate its value. Let’s explore these:

Creating Effective Sensitivity Labels (Microsoft Purview)

Sensitivity Labels allow you to classify and protect documents and emails by their sensitivity level. To create effective labels, follow these guidelines:

• Define a Clear Classification Taxonomy: Start by deciding on the label categories that make sense for your business. Use common, easily understood names for labels so that users intuitively know what to apply. For example, a typical scheme might be: Public (no sensitive data), Internal (within company only), Confidential (sensitive data, limited to certain groups), Highly Confidential (very sensitive, need encryption). Microsoft’s default labels use names like Personal, General, Confidential, Highly Confidential as a starting point. Tailor it to your needs – e.g. you might have a label for “Client Confidential” if you handle client data that needs special care. Avoid too many labels; keep it simple initially (3-5 main labels). You can use sublabels if needed to nest more specific tags under a broader category.
• Specify Protection Settings Per Label: For each label, decide what protections or markings to apply. At minimum, you can have labels just as visual tags, but the real power is in enforcement: For a low-tier label (Public), you might have no encryption and maybe a footer that says “Public”. For an Internal label, perhaps add a footer or watermark “Internal Use Only”. For a Confidential label, you likely want to encrypt the content so only specific groups can open it (and optionally prevent forwarding or editing). For Highly Confidential, you definitely apply encryption (choosing the scope – e.g. only people inside your org, or only members of certain departments) and add watermarks on documents. For emails, a Confidential label might trigger encryption of the email (using Office 365 Message Encryption). Align the protection with the sensitivity: not all data needs heavy encryption, but your most sensitive data should have strong controls (encryption, rights restrictions, etc.) automatically applied when labeled.
• User Guidance and Tooltips: When creating labels, you can include a tooltip/help text that users see when they hover over the label in Office apps. Use this to explain when to use each label (e.g. “Confidential: Use for customer data, financial records, or any sensitive info. Encrypts content; do not share externally.”). Keep the description concise – users won’t read a paragraph. Providing examples in the tooltip (“e.g. design documents, project roadmap”) can be very helpful. Microsoft’s guidance emphasizes testing the labels and tooltips with users to ensure they make sense.
• Publish in Phases: Once labels are defined and configured, you need to publish them via label policies to users. A best practice is to pilot the labels with a small group first. For instance, roll out to IT or a specific department, gather feedback, then adjust if needed, and then expand to the whole organization. Label policies also let you enforce defaults (e.g. all new emails get Internal by default) or require justification to downgrade a label – use these features carefully (they add security but also user friction). Perhaps initially, just make labels available and not mandatory, then later consider mandatory labeling if adoption is good.
• Automate Labeling for Scale: For large organizations or to reduce user burden, consider using auto-labeling rules or AI. Microsoft Purview can automatically apply a label if content matches certain sensitive info types (e.g. if a document contains a credit card number, auto-label it Confidential). This requires higher licenses (E5) and planning to avoid false positives, but it greatly helps in catching unlabeled sensitive files. Even without E5, you can use auto-labeling for Office docs and emails in transport (with some limitations on number of files per day).

An effective sensitivity labeling program means employees see clear labels in their Office apps (e.g. a Sensitivity button showing the labels) and know how to use them. Over time, most internal content might end up as Internal or Confidential by default. A common outcome: one company established labels “Public, Partners-Only, Confidential, Highly Confidential”. They found that within 3 months, employees were routinely labeling emails and files. Their finance team labeled quarterly reports as Highly Confidential (which encrypted them to only executives), and their HR labeled personnel files as Confidential (encrypting to HR group). This not only protected the files but also gave the company insight via the Compliance portal’s analytics on how much sensitive data they have and where. It’s a journey – start simple, communicate the scheme, and iterate. Microsoft provides default label sets which you can reference as examples.

Implementing DLP for Teams, OneDrive, and SharePoint

Data Loss Prevention (DLP) policies in Microsoft Purview help prevent sensitive information from being shared or leaked inappropriately, whether in files or in communications. Implementing DLP across Teams, OneDrive, and SharePoint involves:

• Identify Sensitive Data to Protect: First, decide what types of information are sensitive for your business – e.g. personal data (like credit card numbers, SSNs), health records, financial info, or confidential project keywords. Microsoft provides many built-in Sensitive Info Types (like EU GDPR data, ABA routing numbers, etc.). You can also create custom types (for example, a project code name or proprietary formula patterns). Knowing this, you can create DLP rules to detect these in content.
• Create DLP Policies with Proper Scope: In the Purview compliance portal, create a DLP policy and select the locations: SharePoint sites, OneDrive accounts, and Teams chat can all be selected. To cover files shared in Teams, you actually rely on SharePoint/OneDrive because Teams files are stored there. In fact, Microsoft notes: “Your DLP policy must include SharePoint and OneDrive for protection to be enforced in Teams”. So typically, one policy can cover all three: choose all SharePoint sites, all OneDrives, and Teams chats. (Or scope it to specific sites/users if you prefer a phased rollout.)
• Define DLP Rules – Conditions and Actions: For example, a rule might be: “If a file in SharePoint or OneDrive contains a Credit Card Number and is shared with people outside the organization, then block access to external users and notify the user.” For Teams chats, a rule could be: “If a message contains sensitive info (say, a nine-digit number that looks like SSN), prevent it from being sent to external participants and alert the user with a policy tip.” In practice, when someone attempts to share, the DLP engine will detect it and take action in near real-time. In Teams, the message containing sensitive info can be automatically deleted or blocked within seconds, with the sender getting a notice. For files, external sharing can be blocked – e.g. if you try to share a “Confidential.xlsx” with a guest user, DLP can stop that and show you a warning.
• Policy Tips and User Education: Enable policy tips in DLP so that users get feedback. For instance, in Office or Teams, they might see “This message contains sensitive info and was blocked.” You can allow overrides with justification in some cases – e.g. maybe you allow a user to override a DLP block if they provide a business justification (which is logged). This depends on your internal policy (strict vs. permissive). Many organizations start in a monitor or audit mode – DLP just logs incidents and shows tips without actually blocking, to gauge frequency and fine-tune rules. Then switch to enforce (block) when comfortable.
• DLP for Teams Chat specifics: DLP in Teams covers chat and channel messages (including private channel messages) when you have E5 licensing. It will not retroactively delete messages, but actively monitors as messages are sent. It only works for users internal to your tenant (guests and externals are considered targets, but you can’t scan messages sent by an external in your tenant’s chat). Essentially, if one of your users tries to send out sensitive data in Teams, DLP can nix it if the recipient is outside or even if inside if that violates policy. For example, an employee attempting to post a list of customer SSNs in a Teams channel that has a guest – that message would be auto-removed and the guest wouldn’t see it.
• DLP for SharePoint/OneDrive: This primarily covers preventing sensitive info from being shared in files. A popular policy is “Block sharing of content externally if it contains sensitive info.” The action typically is: if a file violates policy, DLP will restrict its access (e.g. remove external users or convert it to only owner can see until remediated). The user sharing gets notified. Another common action is to send an alert to a compliance officer or log the event for review.

By implementing these, you achieve scenarios like: An HR document with employee NPPI (Non-public personal info) stored on a manager’s OneDrive – if they accidentally try to share it with “Everyone” or external Gmail, DLP will stop it. Or if someone in finance accidentally pastes a customer’s credit card number into a Teams chat with a vendor, DLP will delete that message in real-time. These controls greatly reduce accidental data leaks.

Licensing note: Office 365 E3 includes DLP for files (SharePoint/OD/Exchange), but Teams chat DLP requires E5. For Business Premium, currently Teams DLP isn’t included (as BP aligns to E3). So SMEs may focus DLP on SharePoint/OneDrive primarily, unless they have an add-on for advanced compliance. Even without Teams chat scanning, just stopping sensitive files from leaking externally is a huge win.

Case Studies: DLP in Action

To appreciate the value of DLP, consider a few real-world examples of businesses using it to prevent data leaks:

• Financial Services (Alloy): Alloy is a fintech company that implemented DLP to protect client PII (Personally Identifiable Information) such as Social Security Numbers and tax IDs. They were concerned about both malicious insiders and accidental sharing. By deploying an endpoint DLP agent and cloud DLP, Alloy can now detect if an employee tries to copy a list of SSNs to a USB drive or upload it to a personal cloud account. In fact, it was imperative for Alloy to secure data from insider threats and accidental loss via endpoints and removable media. Since rollout, they have caught and blocked several attempted downloads of client data to USB sticks – something that previously went unmonitored. DLP policies either encrypted the data on the USB or blocked the transfer, logging an incident for IT to follow up. This gave Alloy confidence that sensitive client data stays within authorized channels.
• Healthcare (Spectrum of Hope): Spectrum of Hope, a healthcare provider, needed to protect patient information (which is regulated by HIPAA). They utilized DLP (via Endpoint Protector solutions) to monitor and control data transfers. One notable outcome: they prevented an incident where an employee mistakenly tried to email a report containing dozens of patient records to an external consultant in plaintext. DLP’s content scan recognized the email had multiple patient names, IDs, and diagnoses (matching a “Medical info” rule) and automatically blocked the email, instead alerting the compliance officer. The employee was then guided to use an approved secure portal to share such data. This improved compliance and security of patient data with minimal disruption to workflow.
• Public Sector (NHS Ambulance Service): An NHS ambulance service in the UK (South East Coast Ambulance) wanted to ensure all staff devices that might handle personal data were secure. They used device-level DLP and device control to enforce encryption on USB drives and block unapproved devices. For example, if a staff member plugged in a personal USB drive, the system would prevent copying of files to it unless it was an encrypted, organization-issued drive. They also enforced full disk encryption on laptops with DLP checks to validate it. This was crucial after a prior incident where a lost unencrypted USB stick caused a data breach. Post-DLP implementation, they have had zero incidents of lost devices leading to data leakage – any lost USB or laptop is known to be encrypted and safe.
• Banking (Kompanion Bank): This bank deployed DLP to protect customers’ financial data and PII across their endpoints and cloud. They set policies to monitor emails and file uploads for any account numbers or personal data leaving the organization. Within the first month, DLP alerts revealed an employee was regularly sending spreadsheets of customer info to a personal email to work from home. This was flagged and blocked; the employee was retrained to use the bank’s secure VPN and VDI for remote work instead – a potentially major data leak averted. Kompanion also saw value in DLP reports that showed where sensitive data lived and how it was being used, helping them tighten access controls around those datasets.

These case studies highlight that DLP is not just a theoretical tool – it has concrete impact. It catches the mistakes (or malicious moves) that otherwise go unnoticed until it’s too late. Across industries like pharma, finance, healthcare, and government, DLP has successfully prevented data from “walking out the door,” whether via an email, USB, or cloud app. When implementing DLP, it’s important to fine-tune it to your workflows (to minimize false positives), and to have an incident response process (so when a DLP alert triggers, someone reviews it and educates the user or takes action). Businesses that use DLP effectively often integrate it with their security operations.

Each of the improvements and practices discussed – from Secure Score-driven changes, to enforcing MFA and Conditional Access, to locking down devices and data – not only raises your Secure Score but genuinely strengthens your security posture. Cyber threats continue to evolve, targeting users through phishing, exploiting unmanaged devices, and seeking out sensitive data. By taking a layered approach (users, email, devices, data) as outlined, an organization can dramatically reduce its risk.

For an SME using Microsoft 365 Business Premium or an enterprise on Microsoft 365 E3/E5, leveraging these built-in capabilities is both cost-effective and efficient. You’ll meet many compliance requirements along the way and build trust with customers and partners who ask “Are you secure?” – because now you can confidently answer that you have measurable, robust protections in place. Maintaining a high Secure Score should be seen as a continuous improvement journey; use it to track progress, report to leadership in business terms, and benchmark against peers. As the threat landscape grows, this proactive stance on security – implementing best practices and monitoring via Secure Score – is essential to keep your business safe and resilient.