The Enterprise M365 Baseline
A fully standardized, production-ready Microsoft 365 environment built on industry security frameworks. Phish-resistant by design, automated from day one, and deployed in hours — not weeks.
The Enterprise Baseline is licensed separately from the CONFIG365 platform. Contact us for more information.
How Microsoft 365 Accounts Actually Get Compromised
Almost every breach we see starts in one of two ways — and neither is stopped by a strong password and a standard MFA prompt. Both attacks steal the session token issued after a successful sign-in, which is why the user is never asked to approve anything again.
Want the longer version, including how the device gets compromised in the first place? Read the full breakdown.
This is what the Enterprise Baseline is built to prevent. Phishing-resistant sign-in, compliant-device enforcement, token protection and automated response are configured on day one — then deployed identically to every tenant and monitored for drift, so they stay on.
What You Get Out of the Box
Every deployment includes these capabilities from day one.
Zero Trust Security, By Default
The baseline is built on Zero Trust principles — never trust, always verify. Every access request is authenticated, authorized, and continuously validated regardless of network location, user, or device.
Verify Explicitly
Every sign-in is evaluated against identity, device health, location, and risk signals — no implicit trust granted by default.
Least Privilege Access
Users and devices receive only the minimum access needed. Admin rights are stripped, guest permissions scoped, and privileged roles tightly controlled.
Assume Breach
The environment is designed assuming attackers may already be present — segmentation, monitoring, and automated incident response are built in from day one.
Identity Protection
Entra ID Identity Protection continuously evaluates sign-in and user risk, triggering automated remediation when anomalies are detected.
Device Trust Enforcement
Only Intune-managed and compliant devices can access company resources. Unmanaged endpoints are blocked at the Conditional Access layer.
Microsoft Framework Aligned
Configurations align with Microsoft's Zero Trust deployment guidance and industry security frameworks out of the box.
Device Compliance as the Access Gate
Company data is accessible only from registered devices meeting vital security criteria. High-risk, unmanaged computers are blocked automatically — creating a phish-resistant perimeter.
Why this blocks identity-based attacks
Modern phishing attacks — including tools like Evilginx — bypass traditional MFA by stealing session tokens or browser cookies from compromised devices. With device compliance enforcement, stolen credentials and session tokens are useless: Microsoft 365 continuously re-evaluates device compliance on every request, so an attacker authenticating from an unmanaged device is blocked instantly — even with valid credentials and a stolen session cookie.
InfoStealer malware follows the same logic — it can extract saved passwords and session tokens from a compromised browser, but the access attempt will fail because the attacker's device is not Intune-compliant. No managed device, no access.
Device Requirements Enforced
- • Drive encryption (BitLocker / FileVault) must be active
- • Antivirus solution running and up to date
- • Minimum OS version enforced — no outdated systems
- • Secure Boot and TPM presence validated
- • Firewall must be enabled and reporting
Non-Compliant Device Options
Users on non-compliant or unmanaged computers can optionally authenticate via phish-resistant methods for browser-only access:
- • YubiKey (USB security key) — phish-resistant sessions
- • Passkey-grade MFA for browser access
- • No local data sync permitted outside managed devices
Evilginx / AiTM Phishing
Session tokens are bound to device compliance. Even a stolen token cannot be used from a non-compliant device — the Conditional Access check blocks the request.
InfoStealer Malware
Malware extracting browser cookies or saved credentials from a compromised PC cannot replay them — access is denied because the attacker's device is not enrolled or compliant.
Credential Stuffing
Leaked username and password combinations are useless without a managed, compliant device. Attackers cannot satisfy the Conditional Access policy from an unknown machine.
Zero Trust Conditional Access Policies
Five layered policies enforce Zero Trust authentication. Exclusions and extra rules can be scoped per user or device using Security Groups.
MFA Enrollment Required
Microsoft MFA must be used — all users are required to enroll, including configuring multiple password-reset options.
Azure Virtual Desktop Access
AVD is accessible with standard MFA. Security can be increased to require phish-resistant MFA for AVD sessions.
Browser Access to Microsoft 365
Browser access to all M365 resources requires phish-resistant MFA — via YubiKey, Intune-compliant device, or App Protection Policy device. Session persistence is disabled. Sessions time out after 8 hours.
Locally Installed Applications
Applications such as Teams and Outlook can only be accessed from Intune-managed devices. This ensures no company data is synced to unprotected computers and all data remains on encrypted, managed devices.
Extra Security Rules & Exclusions
Additional rules and targeted exclusions can be applied granularly using Security Groups — for example, service accounts, break-glass accounts, or legacy application exceptions.
Suitable for Every Environment
The baseline is designed to work across all deployment scenarios. Security Groups provide the flexibility to scope exclusions per machine and application — no manual policy changes required.
Standard managed endpoints — all policies apply as-is, full compliance enforcement from day one.
Security Groups arrange exclusions across CA rules, configuration policies, and compliance policies — AVD sessions remain accessible without weakening the overall security posture.
Same Security Group-based exclusion mechanism — scoped per machine and application, keeping enforcement intact everywhere else.
App-Level CA Exclusions via Custom Security Attributes
Instead of hardcoding App IDs into each Conditional Access policy, applications are tagged with a Custom Security Attribute. All relevant CA policies automatically exclude any app carrying the appropriate tag — no policy edits required.
-
IntuneComplianceExcludedAll Intune compliance policies -
ModernIntuneComplianceExcludedDesktop / modern client compliance only -
MobileIntuneComplianceExcludedMobile compliance only -
MobileAppProtectionExcludedMobile app protection only -
BrowserIntuneComplianceExcludedBrowser compliance only -
BrowserStrongAuthExcludedBrowser strong auth only
- Azure Virtual Desktop
IntuneComplianceExcluded - Azure VPN
IntuneComplianceExcluded - Azure Windows VM Sign-In
IntuneComplianceExcluded
These apps run in contexts where device compliance cannot be evaluated — they must be excluded from compliance-gating policies to remain functional.
Encryption Enforced Across All Platforms
Intune configuration profiles auto-encrypt Windows and Mac local drives. Recovery keys are stored securely in Entra ID. USB drives can be encrypted with a password.
Auto-encryption enforced via Intune. Recovery keys escrowed to Entra ID.
Mac drives are auto-encrypted via Intune configuration profiles. Recovery keys are stored in Entra ID for centralized management.
- • iOS and Android: encrypted via App Protection Policies or full Intune enrollment profiles
- • USB drives: can be encrypted with a password using Intune policy
Passwordless MFA at Sign-In
Users configure Windows Hello for Business during first sign-in. PIN, fingerprint, facial recognition, and Bluetooth phone are all supported as second factors.
Supported Authentication Factors
Deployment Notes
- Users are guided through WHFB configuration on first sign-in
- Two-factor sign-in is enabled by default (any combination of PIN, fingerprint, camera, or Bluetooth)
- Per-device exclusions can be set using Security Groups (e.g., shared kiosks or legacy hardware)
Secure Microsoft Apps Without Full Enrollment
App Protection Policies secure Microsoft applications on iOS and Android without requiring full Intune enrollment — increasing user experience without sacrificing security. Full enrollment is required for native app access.
App Authentication
PIN code, Face ID, or fingerprint required to open any Microsoft app on mobile.
Data Encryption
Encryption applied to all Microsoft app data. iOS and Android backups of app data are disabled.
OneDrive-Only Storage
Data storage within Microsoft apps is limited to OneDrive, preventing leakage to personal cloud storage.
Defender for Endpoint Required
Microsoft Defender must be installed on the device for vulnerability management and threat signals.
Minimum OS Enforced
Devices on unsupported OS versions are blocked. Older phones unable to update must be replaced.
Rooted Devices Blocked
Rooted or jailbroken devices are automatically blocked from accessing company data via Microsoft apps.
Centrally Controlled — No Local Overrides
Local merge for Firewall and Defender exclusions has been disabled. This prevents malware from creating its own exclusions before downloading a payload — a common attack vector.
No exclusions are configured by default
All unsolicited inbound connections are blocked by default
Any required exclusions must be configured centrally via Intune
Automated, Wave-Based Patching
Windows updates are handled by Windows Auto-Patch. Devices are divided into waves and patches are approved and monitored by Microsoft automatically.
Windows Auto-Patch
- • Devices divided into deployment waves for staged rollout
- • Patches automatically approved per wave schedule
- • Results and issues monitored and troubleshot by Microsoft
- • Minimizes risk from a bad patch affecting all devices simultaneously
Edge Update Settings
Due to the higher risk and impact of browser vulnerabilities, Edge updates are configured with stricter deadlines:
- • Updates checked and installed every 2 hours
- • User is prompted to restart Edge regularly
- • Auto-restart deadline set at 2 days after update availability
Optimized Windows Experience by Default
Several tweaks and optimizations are applied to all users automatically — covering productivity, security hardening, and configuration management.
Productivity & Convenience
- → Edge auto sign-in with work account
- → Edge profile sync — same bookmarks and settings on all devices
- → Edge ads and news blocker enabled
- → Edge search engine set to Google
- → OneDrive auto sign-in
- → OneDrive Known Folder Move (Desktop, Documents, Pictures)
- → Azure Virtual Desktop auto-subscribe
Security Hardening
- → Local admin rights stripped from standard users
- → BitLocker auto-encryption
- → Attack Surface Reduction (ASR) rules
- → Defender SmartScreen enabled
- → Protected folders (Controlled Folder Access)
- → Network Protection
- → Device lock settings and time client configuration
Unified Endpoint Control
Intune is the central management plane for all security products, application deployment, update settings, and compliance enforcement across Windows, macOS, iOS, and Android.
App Deployment
Applications deployed automatically to enrolled devices. New devices self-configure on sign-in.
Security Enforcement
Windows Firewall, Defender, BitLocker, and Update settings all enforced via configuration profiles.
Compliance Requirements
Entra ID requires compliant devices. Restrictions include minimum OS version, Secure Boot, TPM, and BitLocker.
Defender Integration
Connected to Defender for Endpoint for real-time device risk level signals that feed into Conditional Access.
End-to-End Microsoft Defender Coverage
Defender provides deep integration across endpoints, email, and servers — with risk-level signals feeding directly into Intune Conditional Access. The Defender for Endpoint license is included in Microsoft 365.
- • Auto-enrollment for Windows and Mac desktops
- • iOS and Android client with vulnerability management and web content scanning
- • EDR cloud protection with real-time file reputation scans
- • Network Protection
- • Controlled folder access — limits process access to OneDrive/Documents
- • Attack Surface Reduction rules (Office, Adobe, WMI, and more)
- • Web protection and content filtering
- • SmartScreen
- • Auto-investigation and remediation
- • Intune risk level integration — access limited during active threats
- • Vulnerability management
- • Included in Microsoft 365 license
- • High-end email security layer
- • ZAP — Zero-hour Auto Purge: newly detected spam is deleted from all mailboxes even after delivery
- • Safe Attachments — sandboxed scanning of all email attachments
- • Safe Links — real-time URL detonation and rewriting
- • Anti-spam and anti-malware controls
- • Recommended for a unified EDR and vulnerability management solution across servers and endpoints
- • Same detection techniques as Defender for Endpoint
- • Alerts on network threats such as RDP brute-force attacks
Application Execution Whitelisting
AppLocker limits the locations from which executables, scripts, and installers can launch. This blocks malicious scripts or executables before they can do any harm — catching threats that traditional antivirus often misses.
What AppLocker Blocks
- • Executables launched from non-whitelisted paths
- • Scripts run from user-writable locations
- • Installers from unauthorized sources
- • Malware that downloads and runs payloads from temp directories
Note: Specific rule details are not made publicly available for security reasons.
Onboarding Process
Implementing AppLocker involves a whitelisting phase during which all legitimate business applications are identified and approved before enforcement begins.
- 1. Audit mode enabled to discover all running apps
- 2. Legitimate applications added to the whitelist
- 3. Enforcement mode activated
Automated App Deployment at Scale
Multiple deployment methods ensure new devices and users get their applications automatically on enrollment. A dedicated packaging team is available for complex legacy applications.
- • Community repository with thousands of apps (browsers, tools, etc.)
- • Easily scripted and deployed via Intune
- • Simple install:
choco install app -y
- • Applications recorded and deployed in a virtual bubble
- • Easy install, uninstall, and update lifecycle
- • Distributed to managed Windows devices via Intune
- • Smooth installation without conflicts
- • Requires expertise — dedicated packaging team available
- • Used when Chocolatey and MSIX are not viable
- • Full control over installation logic via PowerShell scripts
- • Deployed and managed through Intune
Automated Vulnerability Management
Defender for Endpoint scans and alerts for potential vulnerabilities across Windows and mobile. Applications are automatically updated where possible, using a custom automation script and our privately hosted software repository.
Automated Updates
- • Third-party applications auto-updated via custom automation script
- • Privately hosted software repository — no rate-limiting, malware-scanned
- • Mobile device OS minimum versions enforced via Intune
User Notifications
- • Daily desktop toast notifications for non-managed software updates
- • Weekly email digest of vulnerability alerts
- • Users prompted to take action before security risks escalate
Defender for Endpoint continuously scans devices and surfaces CVEs, exposure scores, and remediation recommendations.
Protection Against MITM Attacks
Using custom CSS and a server-side solution, every Microsoft 365 login session is validated in real time. This defends against Man-in-the-Middle attacks where proxy tools like EvilGinx are used to steal sessions — bypassing even standard MFA.
Threat: MITM / EvilGinx Attacks
A proxy server records the user's full session — capturing credentials and session tokens. Standard MFA does not protect against this type of attack. The attacker replays the session immediately after capture.
Our Solution: Session Validation
Our servers validate each login session in real time. Anomalies are flagged automatically — the user sees a red background and warning text on the Microsoft 365 login page. A safe login is confirmed by the branded company logo appearing in the bottom-left corner.
How It Works
User begins Microsoft 365 login — custom CSS is loaded from our servers
Server validates the session origin on every authentication request
If anomaly detected: red background + warning text displayed on the login page
If session is safe: branded company logo confirms authenticity in the bottom-left corner
Deployed by Code, Not by Hand
Most Intune policies, configuration profiles, Conditional Access rules, security groups, and Entra settings are deployed using our automation platform — based on a standardized Microsoft 365 environment kept to the highest industry standard.
All configurations deployed via PowerShell automation scripts — fast, repeatable, and auditable.
All options are granular and applicable to specific users and devices via targeted security groups.
Kept in compliance with all popular security frameworks and Microsoft's own recommendations.
Full Configuration Scope
The platform deploys and manages configuration across every major Microsoft 365 workload — not just Intune and Conditional Access.
Conditional Access
- → 47+ Security Groups
- → Access policies
- → Named Locations
- → Assignment Filters
Intune — Device
- → Compliance policies
- → Settings Catalog profiles
- → PowerShell scripts
- → Autopilot profiles
Intune — Apps
- → App protection policies
- → App configuration policies
- → Application packaging
- → Assignment management
Exchange Online
- → Transport rules
- → Mail flow policies
- → IRM & OME configuration
- → OWA policies
Entra ID
- → Authentication Methods (FIDO2, TAP, SMS)
- → Device registration & LAPS settings
- → Custom Security Attributes
- → Enterprise App registrations
Microsoft Teams
- → Tenant-wide Teams settings
- → Messaging & meeting policies
- → External access policies
- → App permission policies
SharePoint Online
- → Graph tenant sharing settings
- → SpoTenant configuration (PnP)
- → External sharing policies
- → Default site permissions
Consent & Permissions
- → Consent permission classifications
- → Admin consent workflows
- → OAuth app policies
- → Delegated permission grants
Information Protection
- → Sensitivity labels (AIP)
- → Publishing policies
- → Auto-labeling
- → DLP policies & rules
Security Groups as Code
All baseline security groups are defined in JSON and deployed automatically. The
{{GROUP:name}}
placeholder system resolves group names to IDs at deploy time — so one baseline works across every tenant without manual ID hunting.
What Gets Deployed
- • Device groups with dynamic membership rules
- • User groups (Modern Workplace Users, admin exclusions)
- • AppLocker exclusion groups (Script, MSI, EXE, APPX)
- • Conditional Access targeting and exclusion groups
- • Intune policy assignment groups
How It Works
- • Groups defined in JSON — one file per group
- • Idempotent: creates if missing, verifies/updates if present
- • Dynamic membership rules preserved across runs
- • Group IDs resolved at runtime — no hardcoded GUIDs in policies
- • Requires
Group.ReadWrite.AllGraph permission
{
"displayName": "Baseline – Modern Workplace Devices",
"description": "All managed endpoints targeted with Intune policies.",
"securityEnabled": true,
"membershipRule": "(device.deviceOSType -eq \"Windows\")",
"membershipRuleProcessingState": "On",
"groupTypes": ["DynamicMembership"]
}Win32 LOB Apps from Git
Deploy Windows applications to managed devices directly from your baseline repository.
Drop a package definition into /apps/chocolatey/ or /apps/winget/
and the pipeline wraps it as a Win32 LOB app, uploads it to Intune, and assigns it automatically.
- • Packages from your private Choco repository
- • Wrapped as Win32 LOB and pushed to Intune
- • No rate-limiting, malware-scanned source
- • Auto-update lifecycle managed by CONFIG365
- • Packages from the WinGet public catalog
- • Wrapped as Win32 LOB for Intune deployment
- • Thousands of apps available without custom packaging
- • Ideal for standard business applications
- • Service principals deployed from JSON
- • App roles and delegated permissions pre-configured
- • CA exclusion tags applied automatically
- • Consistent across all tenants
Managed via the Pipeline
Chocolatey, WinGet, and Enterprise App deployments are each controlled by a separate feature toggle in the pipeline. They can be enabled per-tenant and run alongside all other baseline deployments in the same pipeline run.
MFA Methods Deployed as Code
Authentication method policies control which MFA options users can register and use. CONFIG365 deploys and enforces these settings via the Authentication Methods API — ensuring every tenant has the same phish-resistant method configuration from day one.
Passkey-grade phish-resistant authentication. YubiKeys and any FIDO2-certified hardware key.
Time-limited passcode for bootstrapping passwordless or recovering a locked account.
Number matching push notifications. Passwordless phone sign-in enabled where supported.
Disabled by default. Can be enabled per-tenant for legacy application compatibility.
Policy Scope
Each authentication method can be scoped to all users, specific groups, or excluded for certain groups. CONFIG365 deploys these scoping rules from JSON alongside the rest of the baseline — no manual Entra ID portal editing required.
Identity Platform Configuration
Device registration, LAPS, and self-service password reset settings are deployed and enforced from the baseline. These tenant-wide identity settings are often configured manually and inconsistently — CONFIG365 standardizes them across every client.
Device Registration
- • All users can register devices by default
- • Multi-factor authentication required at join
- • Maximum registered devices per user configurable
- • Enterprise State Roaming scoped to target groups
Windows LAPS
- • Local Administrator Password Solution enabled
- • Passwords escrowed to Entra ID — no shared admin passwords
- • Password complexity and rotation schedule enforced
- • Post-authentication action: reset password on use
Self-Service Password Reset
- • SSPR enabled for all users
- • Two methods required for reset
- • Write-back to on-premises AD where applicable
- • Registration campaign enforced on sign-in
Sensitivity Labels & DLP as Code
Microsoft Purview sensitivity labels, publishing policies, auto-labeling, and DLP are backed up nightly and deployed
from JSON under deployInformationProtection.
Exchange message encryption (IRM/OME) deploys separately under deployExchange.
Label Taxonomy
- • Public → General → Any user (internal or external) → Confidential (with sub-labels)
- • Standalone Any user label encrypts for authenticated guests without Confidential classification
- • Confidential and Highly Confidential tiers
- • Container labels for Groups, SharePoint sites, and Teams
- • Content marking footers and encryption per classification
What Gets Deployed
- • Sensitivity labels and publishing policies
- • Auto-labeling policies and rules
- • DLP policies and rule definitions
- • Promote from backup via policy viewer — no manual Purview portal edits
Collaboration Guardrails by Default
Tenant-wide SharePoint sharing policies and Teams configuration are deployed as code — eliminating the unsafe defaults Microsoft ships with and ensuring consistent collaboration security posture across every client.
SharePoint Online Settings
- • Graph API sharing settings (sharepoint-tenant.json)
- • SpoTenant properties via PnP (tenant-configuration/*.json)
- • External sharing restricted to authenticated guests only
- • Anonymous "Anyone" links disabled tenant-wide
- • Default link type set to "Specific people" (not org-wide)
- • OneDrive sync restricted to domain-joined / compliant devices
OAuth App Governance at Scale
User and admin consent settings are one of the most commonly misconfigured areas of Entra ID. CONFIG365 enforces a consistent consent policy across all tenants — preventing users from granting over-privileged access to third-party OAuth applications.
What Gets Configured
- • User consent disabled for apps from unverified publishers
- • Admin consent workflow enabled for user requests
- • Permission classifications: Low / Medium / High risk
- • Delegated permission grants scoped and audited
- • Group owner consent disabled by default
Why It Matters
OAuth phishing attacks trick users into granting excessive permissions to malicious apps — bypassing MFA entirely. A user clicking "Allow" on a malicious OAuth app can grant an attacker persistent read access to their mailbox, files, and contacts.