The Microsoft Security Model: Identity Plus Device Plus Data
Many organizations buy Microsoft 365 security licensing and still leave the environment exposed because the controls are deployed as isolated features. Someone turns on MFA. Someone else enrolls devices in Intune. Defender alerts go to a shared mailbox. DLP is discussed later. Each piece helps, but the environment still lacks a coherent security model.
A stronger approach is to connect the control layers:
Identity
Microsoft Entra ID defines who the user is, what role they hold, and whether the sign-in is risky.
Device
Microsoft Intune configures device security and reports whether a device meets compliance requirements.
Threat and data
Microsoft Defender XDR detects attacks, while Microsoft Purview helps protect sensitive information from oversharing or leakage.
Conditional Access should not be a standalone checklist. It should be the decision point that uses identity, device, risk, app, and data signals together.
Start With Microsoft Entra ID
Microsoft Entra ID is the identity foundation for Microsoft 365 and many Azure-connected applications. If identity is weak, every other security layer has to compensate.
A practical identity baseline should include:
- Separate cloud-only emergency access accounts protected and monitored outside normal policies.
- Privileged roles assigned only to accounts that actually need them.
- Administrative roles protected with phishing-resistant MFA where possible.
- Legacy authentication blocked.
- Guest and external collaboration reviewed intentionally.
- Sign-in logs, audit logs, and risky-user processes monitored.
- Privileged Identity Management considered where licensing and risk justify it.
The goal is not merely to require MFA. The goal is to make identity a managed control surface with clear owners, role boundaries, access reviews, and incident-response paths.
Conditional Access: The Policy Engine
Microsoft Entra Conditional Access is Microsoft's Zero Trust policy engine. It evaluates signals such as user, device, location, application, and risk, then decides whether to allow access, block access, require MFA, require a compliant device, require an approved app, or enforce other controls.
Conditional Access policies should normally be designed in rings:
- Report-only testing. Confirm policy impact before enforcement.
- Administrative controls. Protect privileged users, Azure management, security portals, and admin apps first.
- Baseline user controls. Require MFA, block legacy authentication, and reduce high-risk access paths.
- Device-based controls. Require compliant or hybrid joined devices for sensitive applications.
- Risk-based controls. Use sign-in risk, user risk, and session controls where licensing supports them.
| Policy Area | Common Control | Why It Matters |
|---|---|---|
| Admins | Require strong MFA and restrict admin portal access. | Privileged accounts are high-value targets. |
| Legacy auth | Block older protocols that cannot satisfy modern access controls. | Legacy authentication remains a common bypass path. |
| Risk | Require password change, MFA, or block access for risky users or sign-ins. | Risk signals let access decisions adapt to suspicious behavior. |
| Devices | Require compliant devices for sensitive apps. | Access is tied to device health, not just user credentials. |
| Locations | Apply additional controls from untrusted networks or impossible travel patterns. | Network context is not the only signal, but it is still useful. |
Every Conditional Access deployment should preserve emergency access, document exclusions, and maintain a rollback path. Overly broad policies can lock out users, break automation, or disrupt service accounts if they are not planned carefully.
Intune Configuration Profiles: Set the Device Baseline
Microsoft Intune device configuration profiles define settings that devices should receive. This is where the organization configures the security posture of managed endpoints.
For Windows devices, a practical baseline often includes:
- Microsoft Defender Antivirus enabled and updated.
- Firewall enabled for supported profiles.
- BitLocker enabled with recovery-key escrow.
- Windows Update for Business or another approved update model.
- Endpoint detection and response onboarding.
- Local administrator controls.
- Attack surface reduction rules tested and deployed in rings.
- Browser, password, USB, and device restrictions aligned to business risk.
Configuration profiles are the "make the device behave this way" layer. They should be assigned deliberately, tested by device type, and monitored for conflicts.
Practical rule
Do not confuse a configured device with a compliant device. Configuration profiles apply settings. Compliance policies evaluate whether the device meets access requirements.
Intune Compliance Policies: Decide Whether the Device Is Trusted Enough
Intune compliance policies evaluate device status against rules and conditions. Conditional Access can then use that compliance state to decide whether a user can access corporate resources.
A strong compliance model can check whether devices meet requirements such as:
- Encryption is enabled.
- Minimum operating-system versions are met.
- Defender for Endpoint device risk is acceptable.
- Password or PIN requirements are met.
- Jailbroken or rooted devices are blocked.
- Required security settings are present.
Compliance policies should also define what happens when a device becomes noncompliant. Some organizations only notify users. Others block access after a grace period. The right answer depends on data sensitivity, device ownership, user population, and business tolerance.
When compliance results feed Conditional Access, the device becomes part of the access decision. A valid password alone is no longer enough if the endpoint is unmanaged, unencrypted, unhealthy, or high risk.
Microsoft Defender XDR: Detection and Response Across the Estate
The current unified Microsoft detection and response layer is Microsoft Defender XDR in the Microsoft Defender portal. Defender XDR correlates alerts and incidents across Microsoft security services, including endpoints, identities, email, Microsoft 365 services, and cloud apps when the relevant components are licensed and configured.
This matters because identity and device controls reduce risk, but they do not eliminate attacks. Security teams still need a place to see incidents, understand attack scope, review evidence, approve or reject remediation actions, and hunt across signals.
A practical Defender XDR rollout should include:
- Defender for Endpoint deployed and reporting healthy device status.
- Defender for Office 365 policies reviewed for phishing and malicious content.
- Identity and cloud-app signals connected where licensing supports them.
- Incident queues assigned to real owners, not ignored mailboxes.
- Automated remediation settings reviewed and approved by security leadership.
- Action center review included in weekly or daily security operations.
- Advanced hunting used for deeper investigation and recurring checks.
Microsoft continues to evolve the Defender portal and automated investigation experience, so operational runbooks should be reviewed periodically rather than treated as permanent.
Purview DLP: The Cherry on Top for Data Protection
Conditional Access, Intune, Entra ID, and Defender XDR help decide who can access resources, whether their device is healthy, and whether threats are detected. Microsoft Purview adds another question: what happens to sensitive data after access is granted?
Microsoft Purview Data Loss Prevention can identify, monitor, and help protect sensitive information across supported locations, transmission methods, and user activities. It can use deep content analysis, sensitive information types, labels, policy rules, and user notifications to reduce oversharing and data leakage.
Examples of Purview DLP use cases include:
- Warn users before sharing files containing sensitive data externally.
- Block sending regulated data through email without justification or override.
- Monitor sensitive files in SharePoint, OneDrive, Teams, and endpoints where supported.
- Use sensitivity labels to align data classification with handling rules.
- Generate DLP alerts for investigation and policy tuning.
DLP should not be the first security control you deploy. It is the layer that makes the rest of the security program care about the data itself.
A Practical Rollout Plan
Five-Step Security Baseline
Do not deploy everything to everyone in one day. Use pilot groups, report-only mode, staged rings, documented exceptions, and clear communication. Security controls fail when users discover them through broken workflows instead of planned rollout.
Common Mistakes
Turning on MFA but Leaving Legacy Authentication Open
MFA does not help if an older protocol bypasses the control.
Requiring Compliant Devices Before Devices Can Become Compliant
Enrollment and bootstrap workflows need carefully scoped exceptions.
Mixing Too Many Device Settings Into One Profile
Large profiles are harder to test, troubleshoot, and roll back. Group settings by purpose where practical.
Treating Defender Alerts as Someone Else's Problem
Detection without ownership is not security operations. Incidents need assignment, review, and closure standards.
Deploying DLP Without User Education
DLP policies can create frustration if users do not understand what is being protected and how to handle exceptions.
Forgetting Break-Glass Accounts
Every Conditional Access deployment needs protected emergency access accounts and regular validation.
Frequently Asked Questions
What is the difference between an Intune configuration profile and a compliance policy?
Configuration profiles set device behavior and security settings. Compliance policies evaluate whether a device meets requirements. Conditional Access can then use compliance status to allow, block, or require additional controls.
What should Conditional Access protect first?
Start with administrator accounts, legacy authentication, risky sign-ins, sensitive cloud apps, unmanaged devices, and external access paths. Test policies in report-only mode before broad enforcement.
Is Microsoft Defender XDR the current name?
Microsoft Defender XDR is Microsoft's unified detection and response experience in the Microsoft Defender portal. It correlates alerts and incidents across identities, endpoints, email, Microsoft 365 services, and cloud apps when the relevant Defender services are licensed and configured.
Where does Microsoft Purview fit?
Purview adds data protection on top of identity, device, and threat controls. Microsoft Purview DLP can identify, monitor, and help protect sensitive information across supported locations and user activities.
Can small businesses use this model?
Yes. The same layered model works for small and midsize businesses, but policy scope, licensing, deployment rings, exceptions, and monitoring should be matched to the organization's size and risk.
How Fletcher Technology Group Can Help
Fletcher Technology Group helps businesses design, deploy, and operationalize Microsoft security controls across Entra ID, Conditional Access, Intune, Defender, and Purview.
Our services include Microsoft 365 security assessments, Conditional Access design, Intune configuration and compliance profiles, Defender XDR operational readiness, endpoint hardening, administrator-access reviews, Purview DLP planning, and user-friendly rollout support.
Need a Microsoft security baseline that actually works?
We can help you turn disconnected Microsoft security features into a layered, supportable operating model.
Related content
Technical References
- Microsoft Entra Conditional Access overview
- Plan a Conditional Access deployment
- Conditional Access conditions
- Get started with Microsoft Intune
- Configure device features and settings in Intune
- Deploy device profiles in Microsoft Intune
- Device compliance policies in Microsoft Intune
- Plan for Intune compliance policies
- Microsoft Defender XDR in the Microsoft Defender portal
- Microsoft Defender portal overview
- Automated investigation and response in Microsoft Defender XDR
- Microsoft Purview Data Loss Prevention overview