Identity
Strong authentication, conditional access, and identity-layer threat detection across cloud and on-premises Active Directory.
- Entra ID
- Conditional Access
- Strong Auth (MFA)
- Defender for Identity
Our Security Approach
Netlogic operates a comprehensive Microsoft Zero Trust security and governance architecture, delivered through Microsoft 365 E5 and Microsoft Defender XDR + Purview. The same technical baseline we deploy to managed clients is the baseline we run ourselves — because the credibility of a security posture begins with first-person operation, not just recommendation.
What this report covers: The technical and data-governance controls implemented across our endpoints, identities, applications, data, and infrastructure. This is the technical control plane that supports our customers' compliance journeys.
What this report does not claim: Compliance with any framework requires organizational, procedural, and audit-attestation controls beyond technology. We are explicit about the difference. See Transparency.
Microsoft Zero Trust Architecture
Five protected pillars, integrated through Microsoft Defender XDR and Microsoft Purview. Each pillar uses Microsoft-native technology rather than third-party agents that require additional trust boundaries.
Devices
Hardened endpoints under continuous configuration management, with EDR, attack surface reduction, and managed updates.
- Intune
- Defender for Endpoint
- ASR Rules
- BitLocker
- Autopatch
Apps
Application control, cloud app security, OAuth governance, and email protection at the strictest preset Microsoft publishes.
- App Control
- Defender for Cloud Apps
- Defender for Office 365 (Strict)
Data
Sensitivity labeling with auto-classification, data loss prevention, and retention with defensible disposition.
- Purview Information Protection
- Purview DLP
- Purview Data Lifecycle
- BitLocker
- Personal Data Encryption
Infrastructure
Host-based firewall hardened across all profiles, NTLMv2-only, network protection, and unified XDR detection across all signals.
- Windows Firewall
- Defender Network Protection
- Defender XDR
- NTLM Hardening
Implemented Security Controls
Each entry below describes a control we operate, what it protects against, how it's configured, and how it maps to Microsoft documentation. Click any card to expand. Permalinks are available for sharing specific controls.
Every Netlogic-managed endpoint receives a configuration baseline that locks down legacy protocols, removes weak authentication mechanisms, enforces secure boot integrity, and applies SmartScreen protections at the strongest practical settings. The baseline is curated from Microsoft's published Windows 11 25H2 MDM Security Baseline with calibrated, documented exceptions where Microsoft's enterprise assumptions don't fit small-business operating realities.
What it does
- Disables SMBv1 client driver and SMBv1 server feature entirely
- Forces NTLMv2-only authentication with 128-bit minimum session security; refuses LM and NTLM
- Blocks anonymous SAM enumeration, anonymous named-pipe access, and prevents LM hash storage
- Requires NLA for Remote Desktop, blocks WinRM Basic auth and unencrypted traffic
- Disables AutoPlay across all volume types and AutoRun for non-volume devices
- Blocks user-mode Remote Assistance (Solicited and Unsolicited)
- Configures LSA to run as a Protected Process with UEFI lock
- SmartScreen App Install Control set to Warn before installing apps from outside the Microsoft Store
- SmartScreen Prevent Override For Files In Shell — users cannot bypass file warnings
- Enhanced Phishing Protection (WebThreatDefense) — all five components enabled
- Health Attestation required at boot
- IPv6 source routing protection set to Highest
Validation
Configuration drift is detected via Microsoft Intune compliance reporting and Microsoft Defender Vulnerability Management posture assessment. Baseline updates are versioned (current: Winter 2025) and tracked through a documented review cycle.
Microsoft Defender Attack Surface Reduction rules detect and block specific attacker behaviors — credential theft from LSASS, Office macro abuse, persistence through WMI, USB-borne malware, and more. We operate all eligible rules in Block mode rather than the more permissive Audit mode.
Rules in Block mode
- Block credential stealing from the Windows local security authority subsystem (LSASS)
- Block executable files from running unless they meet a prevalence, age, or trusted-list criterion
- Block process creations originating from PSExec and WMI commands
- Block persistence through WMI event subscription
- Use advanced protection against ransomware
- Block executable content from email client and webmail
- Block abuse of exploited vulnerable signed drivers
- Block execution of potentially obfuscated scripts
- Block Office communication apps from creating child processes
- Block all Office applications from creating child processes
- Block Win32 API calls from Office macros
- Block JavaScript or VBScript from launching downloaded executable content
- Block untrusted and unsigned processes that run from USB
- Block Adobe Reader from creating child processes
- Block Office applications from injecting code into other processes
- Block Office applications from creating executable content
- Block use of copied or impersonated system tools
- Block rebooting machine in Safe Mode
Per-rule exclusions are minimal, documented, and reviewed; the goal is rule integrity, not silent permissiveness. When Microsoft's own diagnostic tooling triggers a rule (e.g., MDE Client Analyzer using PsExec), we add narrowly-scoped, time-bounded exclusions for the duration of the diagnostic and remove them immediately afterward.
Controlled Folder Access blocks unauthorized writes to disk sectors (boot record, MBR, VBR) — the destructive ransomware behaviors that wipe filesystems entirely. We operate the feature in Block disk modification only mode, paired with an extensive allowed-applications list covering Microsoft Office (x64 and ARM64), Edge, Edge WebView2, Microsoft Teams, new Outlook, Phone Link, OneDrive (per-user and per-machine), and CrossDeviceService.
Why this configuration
The most aggressive CFA setting (full Block mode) creates productivity friction for legitimate developer and IT-operations workflows. We chose disk-modification-only mode, which protects against destructive ransomware behavior without blocking file writes by trusted applications. Combined with the 18 ASR rules and ransomware-specific protections, the layered control surface is comprehensive.
Microsoft App Control for Business (formerly Windows Defender Application Control) enforces code-signing requirements at the kernel level. Our policy trusts Microsoft components and Microsoft Store apps, and runs in Audit mode to capture would-block events without disrupting legitimate workflows during the supplemental-policy authoring phase.
Why Audit, not Enforce
Per Microsoft's published guidance, App Control should run in Audit mode for 4–8 weeks before enforcement so that all line-of-business applications can be inventoried and explicitly allowlisted via supplemental policies. Premature enforcement breaks unsigned LOB apps, login scripts, and developer tooling. The transition path requires comprehensive supplemental policies (publisher-based where signed, hash-based where not, path-based as last resort) before Enforce is safe to apply broadly.
What's protected today
Even in Audit mode, App Control logs every binary that would be blocked, providing forensic visibility for incident response. Combined with Microsoft Smart App Control on eligible devices and our 18 ASR rules, executable trust is comprehensively monitored.
Full-disk encryption is enforced on all managed devices. BitLocker enables silently using the device's TPM, with the recovery password auto-rotated and escrowed to Microsoft Entra ID. Removable drives have cross-organization write access blocked, and Personal Data Encryption (PDE) provides additional file-level protection.
Configuration
- Operating-system drive: encrypted (XTS-AES) with TPM auto-unlock
- Fixed data drives: encrypted
- Removable drives: cross-organization write access blocked
- Recovery key: auto-rotated, escrowed to Entra ID
- Standard users authorized to enable encryption (required for silent enablement on Entra-joined devices)
- Personal Data Encryption (PDE) enabled with Windows Hello for Business as the unlock authenticator
Kernel DMA Protection
Beyond drive encryption, kernel DMA protection blocks external Thunderbolt/PCIe DMA attacks while the screen is locked, and DMA Guard enumeration policy permits only DMA-remappable peripherals.
Windows Defender Firewall is enabled on all three network profiles (Domain, Private, Public) with default-block inbound, default-allow outbound, stealth mode active, and successful-connection plus dropped-packet logging at 16 MB log file size. Public profile carries additional hardening: global port user-pref merge disabled, unicast responses to multicast broadcasts blocked.
Operational tuning rationale
Microsoft's Win11 25H2 baseline recommends disabling local-policy merge entirely. We tested this configuration and observed DHCP and NCSI failures on Public-profile networks (where home users land by default). We reverted local-policy merge to True with documented justification, while keeping the user-preference merge controls disabled on Public — a calibrated balance between strict policy and operational simplicity for clients on hotel, café, and home networks. This kind of nuance is what differentiates an experienced MSP-tuned baseline from a blindly-applied vendor template.
Microsoft Defender Antivirus is the primary anti-malware engine on every managed endpoint, running in active mode with cloud-delivered protection at the High block level — Microsoft's strictest cloud-protection tier. Real-time protection, behavior monitoring, IOAV protection, script scanning, network file scanning, email scanning, and on-access protection are all enabled.
Configuration highlights
- PUA Protection enabled
- Network Protection in Block mode
- Cloud Block Level: High; Cloud Extended Timeout: 50 seconds
- Sample submission: Send safe samples automatically
- Threat severity actions: Severe → Remove; High/Moderate → Quarantine; Low → Quarantine
- Signature update interval: 4 hours
- Disable Local Admin Merge: enabled — local admins cannot add exclusions that override Intune
- Scheduled scan on full CPU priority for fast completion; AvgCPULoadFactor capped at 50%
Tamper Protection
Tamper Protection is enforced at the tenant level, preventing local administrators (or malware running with local-admin privileges) from disabling Defender or modifying its configuration.
Microsoft Defender for Endpoint provides cloud-native EDR with behavioral threat detection, automated investigation and response (AIR), threat and vulnerability management (TVM), advanced hunting via Kusto Query Language, and unified incident correlation through Microsoft Defender XDR.
What Defender XDR delivers
- Real-time behavioral detection with millions of telemetry signals from Microsoft's global threat intelligence
- Automated investigation and remediation for common malware patterns
- Live response capability for in-band IR investigations
- Continuous vulnerability scoring per device with prioritization by exploit availability
- Software inventory across the entire fleet with version tracking
- Cross-domain incident correlation: endpoint, identity, email, cloud apps unified into single incident graphs
Defender for Identity monitors authentication telemetry across Microsoft Entra ID and on-premises Active Directory Domain Services, detecting credential theft, lateral movement, privilege escalation, Kerberos abuse (Golden Ticket, Silver Ticket, Skeleton Key), DCSync, DCShadow, and reconnaissance activity that endpoint-only tools cannot see.
Detection coverage
- Account enumeration and reconnaissance
- Brute-force and password-spray attacks
- Pass-the-Hash and Pass-the-Ticket lateral movement
- Golden Ticket, Silver Ticket, Skeleton Key Kerberos attacks
- DCSync and DCShadow domain controller impersonation
- Suspicious sensitive group membership changes
- Identity Security Posture Management (ISPM) recommendations
Defender for Cloud Apps provides Cloud Access Security Broker (CASB) capabilities across sanctioned and unsanctioned SaaS applications. It discovers Shadow IT through endpoint-driven cloud-traffic analysis, governs OAuth-app permissions to Microsoft 365, and enforces session-level controls through integration with Conditional Access App Control.
Capabilities
- Shadow IT discovery from endpoint and proxy logs
- OAuth app inventory with risk scoring and consent governance
- Real-time session policies (block download, prevent print, require labeling) via Conditional Access App Control reverse proxy
- File policies for data classification and sensitivity-label enforcement on SaaS
- Anomaly detection for impossible travel, mass download, suspicious inbox rules
- Activity logging across 25,000+ cataloged cloud apps
Defender for Office 365 protects email, Microsoft Teams, SharePoint Online, OneDrive for Business, and other M365 collaboration surfaces. We apply Microsoft's Strict preset — the highest-tier policy preset Microsoft publishes — and re-validate the configuration through Microsoft's Configuration Analyzer to surface any drift from the recommended Strict baseline.
Strict preset components
- Anti-phishing with impersonation protection (users and domains), spoof intelligence, mailbox intelligence
- Safe Links — URL-time-of-click reputation analysis with detonation in cloud sandbox
- Safe Attachments — dynamic delivery with detonation prior to user access
- Anti-spam with high-confidence phish rejection, spam zero-hour auto-purge (ZAP)
- Anti-malware with attachment filter rules
- Tenant Allow/Block List management
- Attack Simulation Training capability for security awareness
Why Strict matters
Phishing remains the dominant attack vector against small and mid-sized businesses. Microsoft's Standard preset is appropriate for general use; Strict is the more aggressive option, accepted by Microsoft as the highest-protection configuration appropriate for production deployment. We accept the higher false-positive rate as a deliberate trade-off in favor of reduced phishing exposure.
Microsoft Entra Conditional Access is the policy engine that gates resource access. Every authentication is evaluated against signals — user identity, group membership, device compliance state, location, application, and real-time risk score — before access is granted. Strong Authentication is mandatory: multi-factor authentication is enforced at the session level, not as a deferrable prompt.
Active policies
- MFA required for all users on all cloud apps
- Sign-in risk and user risk policies block or require step-up authentication on suspicious sessions
- Compliant device required for access to sensitive resources
- Block legacy authentication protocols (no Basic Auth, no IMAP/POP/SMTP-AUTH)
- Entra Terms and Conditions acceptance required before access — provides written acceptable-use attestation, mapped to HIPAA §164.308(a)(5)(i) Security Awareness
Why this is foundational
Identity is the new perimeter. Without strong authentication enforced at every session, no other security control can rely on the user's identity claim. Conditional Access is the cornerstone of zero-trust architecture and the highest-leverage protection against credential-based attacks (which represent the majority of breach cause analyses Microsoft publishes).
Microsoft Purview Information Protection classifies data based on content (with auto-labeling driven by trainable classifiers and pattern-matching) and applies persistent encryption that travels with the file. A document labeled Confidential remains encrypted whether it sits in SharePoint, an email attachment, a USB stick, or a partner's inbox.
Capabilities
- Trainable classifiers for industry-specific data types (PII, PHI, financial, source code)
- Pattern-based auto-labeling at file creation and rest-scanning of historical content
- Visual marking (header, footer, watermark) on documents and emails
- Encryption-protected labels with usage rights (view, edit, copy, print, forward)
- Cross-organization protection via Microsoft Purview's identity-based encryption
- Co-authoring of encrypted documents in Microsoft 365
Purview Data Loss Prevention enforces consistent data-handling policies across Exchange Online, SharePoint Online, OneDrive for Business, Microsoft Teams, and Windows endpoints. DLP detects sensitive content (PII, PHI, PCI, custom-defined types) and blocks, warns, or audits actions that would result in unauthorized exfiltration.
Coverage surfaces
- Exchange — outbound email containing sensitive content
- SharePoint & OneDrive — external sharing of sensitive documents
- Microsoft Teams — chat and channel messages, file attachments
- Endpoint DLP — local file copy to USB, network share, cloud sync, print, clipboard, screenshot
- Defender for Cloud Apps — non-Microsoft SaaS file movement
Why this matters
Most breach impact stems not from initial intrusion but from data exfiltration that follows. DLP at every egress channel is the technical foundation for HIPAA's "minimum necessary" rule, GDPR's data-protection-by-design requirement, and the FTC Safeguards Rule's encryption requirement.
Purview Data Lifecycle Management enforces retention requirements (keep-and-delete) and supports defensible disposition reviews for records that must be preserved for legal, regulatory, or operational reasons. Retention labels can be applied automatically based on content classification or manually by record owners.
Capabilities
- Retention labels with retain-and-delete or retain-only behavior
- Auto-application of retention labels based on sensitive-info-types or trainable classifiers
- Disposition reviews — multi-stage approval before deletion of records
- Records management with regulatory-grade immutability
- eDiscovery integration for legal hold
The full patching surface — operating system, Microsoft productivity apps, and third-party applications — is managed exclusively by Microsoft-native tooling. No third-party RMM or patching agent is deployed on managed endpoints.
Operating system patching
Windows Autopatch automatically deploys quality updates, feature updates, and driver updates through ring-based progression with telemetry-driven monitoring and automatic rollback for problematic releases. Microsoft maintains the rings, telemetry, and rollback heuristics; we maintain the policy that targets devices to it.
Microsoft 365 Apps patching
Microsoft 365 Apps Cloud Update handles Office Click-to-Run patching with the same telemetry-driven discipline as Autopatch. Edge, OneDrive, Teams, and other Microsoft endpoints update through their own first-party self-update channels.
Third-party application patching
All other installed applications (Adobe Reader, Chrome, Firefox, 7-Zip, Notepad++, Zoom, VLC, Git, and dozens more) are kept current by a daily Intune Remediations script that uses Microsoft's native winget package manager via the Microsoft.WinGet.Client PowerShell module. The script runs as SYSTEM in PowerShell 7, silently and non-interactively, with the following operational characteristics:
- Runs once daily on every managed endpoint
- Inventories installed apps and identifies those with available newer versions
- Updates apps via the supported COM-wrapped PowerShell module — Microsoft's recommended automation surface for SYSTEM context
- Per-app timeout and progress-logging guardrails so a single hung installer cannot stall the run
- Routes problem packages through the
winget.exeCLI fallback path when the PowerShell module is unreliable for a specific app - Per-package pre-update hooks stop background services and processes that would otherwise hold installer locks
- Excludes Microsoft applications managed via dedicated channels (Teams, Office, Edge) to avoid update-channel conflicts
- Writes structured remediation state to disk so the paired detection script surfaces what was updated, what failed, and why — visible in Intune Remediation reports
- Logs to a documented path (
C:\My365 Logs\App Updates\) for offline review when a device escalates - Self-bootstraps the WinGet PowerShell module on first run via PSResourceGet (Microsoft's modern PSGallery client)
- Architecture-aware: locates the appropriate PowerShell 7 binary on both x64 and ARM64 devices
Why this matters for posture
Third-party application patching is a documented and frequently-exploited gap in small-and-mid-sized environments. Most MSPs deploy a third-party RMM agent to close it — which itself becomes a supply-chain risk surface (see the public history of RMM-vendor compromises distributing ransomware). Our approach uses Microsoft-native tooling end-to-end: winget is part of Windows, the PowerShell module is published by Microsoft, and the orchestration runs through Intune Remediations — three components our customers already trust at the platform level.
This eliminates an entire vendor trust boundary while satisfying CIS Controls v8 §7.4 (Perform Automated Application Patch Management) for third-party software — a requirement that's typically met only by purpose-built patching tools.
External devices and removable media are tightly controlled. Kernel Direct Memory Access (DMA) protection blocks external Thunderbolt and PCIe DMA attacks while the device is locked. Removable drive enumeration is limited to DMA-remappable devices. Defender Antivirus performs full scans of removable drives during scheduled scans, and the ASR rule blocks untrusted/unsigned processes from running from USB.
Compliance Framework Alignment
Each framework below shows our technical-control coverage. Coverage is honest and specific: we cite the specific control families addressed by our deployed technology, and we name the gaps that require organizational, procedural, or audit-attestation work beyond technology.
The HIPAA Security Rule (45 CFR Part 164 Subpart C) requires Administrative, Physical, and Technical Safeguards for ePHI. Our architecture implements all Technical Safeguards (§164.312) and the technical components of §164.310 and the Privacy Rule's Minimum Necessary requirement (§164.502(b)).
Technical Safeguards (§164.312) — fully implemented
| Citation | Implementation |
|---|---|
| §164.312(a)(1) Access Control — Unique User ID | Microsoft Entra ID identity |
| §164.312(a)(2)(iii) Automatic Logoff | DeviceLock policy + screen lock enforcement |
| §164.312(a)(2)(iv) Encryption / Decryption | BitLocker + Personal Data Encryption + Purview MIP |
| §164.312(b) Audit Controls | Defender XDR + Entra sign-in/audit logs + MDA + MDI |
| §164.312(c)(1) Integrity | ASR + CFA + Defender for Office 365 Strict + Purview DLP |
| §164.312(d) Person/Entity Authentication | Strong Authentication (MFA enforced via Conditional Access) |
| §164.312(e)(1) Transmission Security | NTLMv2-only, SMB signing always, Defender for Office 365 email encryption |
Privacy Rule technical foundation
Purview Information Protection and DLP enforce the §164.502(b) Minimum Necessary requirement at the data-flow level: sensitive-content classification triggers automatic encryption, DLP blocks unauthorized data transfers, and DLM ensures defensible deletion when retention requirements are met.
What we do not claim: "HIPAA compliant." Full HIPAA compliance requires Business Associate Agreements with all subcontractors handling ePHI, written security policies, security risk analysis (§164.308(a)(1)(ii)(A)), workforce training, designated Security Officer, incident response procedures, contingency planning, and breach notification procedures — none of which are produced by technology alone. We provide the technical foundation; covered entities and business associates complete the administrative and procedural layers.
SOC 2 (Service Organization Control 2) is an attestation framework developed by the AICPA that evaluates organizations against five Trust Services Criteria: Security (mandatory), Availability, Processing Integrity, Confidentiality, and Privacy. Our technical controls substantially meet the Common Criteria related to Security and the Confidentiality criteria.
| Criterion | Status |
|---|---|
| CC6.1 Logical Access Controls | Conditional Access + Strong Authentication + MDI |
| CC6.2 Authentication | MFA enforced at session level |
| CC6.3 Access Provisioning | Microsoft Entra (technical layer) |
| CC6.6 Vulnerability Management | Defender Vulnerability Management + Autopatch |
| CC6.7 System Access Restriction | App Control (Audit) + ASR + Firewall |
| CC6.8 Malware Prevention | Defender + ASR + CFA + MDO Strict |
| CC7.1 Detect Security Events | Defender XDR + MDI + MDA |
| CC7.2 Continuous Monitoring | Defender XDR + Conditional Access App Control |
| CC8.1 Change Management (technical) | Autopatch + Cloud Update for Microsoft 365 Apps |
| C1.1 Confidentiality (data identification & protection) | Purview Information Protection + DLP |
What we do not claim: SOC 2 attestation. A SOC 2 Type II report can only be issued by an independent CPA firm following a six-month-or-longer audit covering policies, procedures, governance, and continuous control operation. Our technical implementation provides a strong foundation, but the report itself requires audit engagement.
ISO/IEC 27001:2022 specifies requirements for an Information Security Management System (ISMS), with 93 Annex A controls grouped into Organizational, People, Physical, and Technological domains. Our architecture substantially implements the Annex A.8 Technological Controls and key Annex A.5 organizational controls related to data classification, transfer, retention, and privacy.
| Control | Implementation |
|---|---|
| A.5.12 Classification of information | Purview Information Protection sensitivity labels |
| A.5.13 Labelling of information | MIP visual marking + metadata persistent labels |
| A.5.14 Information transfer | Purview DLP across Exchange, SharePoint, OneDrive, Teams |
| A.5.23 Information security for cloud services | Defender for Cloud Apps + Conditional Access App Control |
| A.5.33 Protection of records | Purview DLM with disposition reviews |
| A.5.34 Privacy and protection of PII | MIP + DLP + DLM combined |
| A.8.1 User endpoint devices | Intune-managed baseline |
| A.8.5 Secure authentication | Strong Auth + MFA + Conditional Access |
| A.8.7 Protection against malware | Defender + ASR + CFA |
| A.8.8 Management of technical vulnerabilities | Defender VM + Autopatch |
| A.8.9 Configuration management | Intune baseline + Compliance Manager |
| A.8.10 Information deletion | Purview DLM disposition |
| A.8.12 Data leakage prevention | Purview DLP — endpoint + cloud + email |
| A.8.16 Monitoring activities | Defender XDR + MDI + MDA |
| A.8.20 Networks security | Firewall hardening + NTLM hardening |
| A.8.23 Web filtering | SmartScreen + Edge enterprise policy |
| A.8.24 Use of cryptography | BitLocker, NTLMv2, MIP encryption, transport TLS |
| A.8.32 Change management | Autopatch + Cloud Update |
What we do not claim: ISO 27001 certification. Certification requires an established ISMS, scope definition, risk assessment methodology, Statement of Applicability, internal audit, management review, and external audit by an accredited certification body (Stage 1 + Stage 2). Our technical implementation supports the ISMS but does not constitute it.
NIST Cybersecurity Framework 2.0 organizes cybersecurity outcomes into six functions: Govern, Identify, Protect, Detect, Respond, and Recover. Our architecture comprehensively addresses PROTECT and DETECT, with substantial coverage of IDENTIFY and partial coverage of RESPOND.
| Function | Coverage |
|---|---|
| GV (Govern) | Organizational — supported by control documentation |
| ID (Identify) | MDE software + asset inventory + MDA Shadow IT discovery + MDI on-prem visibility |
| PR (Protect) | Comprehensive — Conditional Access, Strong Auth, ASR, CFA, BitLocker, MIP, DLP, MDO Strict, App Control |
| DE (Detect) | Comprehensive — Defender XDR + MDI + MDA + DLP alerts |
| RS (Respond) | Defender XDR auto-investigation/auto-remediation; documented IR procedures additive |
| RC (Recover) | Organizational — DR/BCP planning required |
The Center for Internet Security (CIS) Controls v8 specifies 18 prioritized cybersecurity safeguards organized into Implementation Groups (IG1 = essential cyber hygiene, IG2 = enterprise foundational, IG3 = organizational mature). Our architecture fully implements IG1 device-level safeguards and substantially implements IG2.
| Control | Status |
|---|---|
| 1 — Inventory of Enterprise Assets | Defender for Endpoint inventory + MDA |
| 2 — Inventory of Software Assets | Defender for Endpoint software inventory |
| 3 — Data Protection (all sub-safeguards) | BitLocker + Purview MIP + DLP + DLM |
| 4 — Secure Configuration | Intune-managed baseline |
| 5 — Account Management | Microsoft Entra + Strong Auth |
| 6 — Access Control Management | Conditional Access + MDI |
| 7 — Continuous Vulnerability Management (incl. §7.4 Automated Application Patch Management) | Defender Vulnerability Management + Windows Autopatch + Microsoft 365 Apps Cloud Update + native winget-based daily third-party app patching |
| 8 — Audit Log Management | Defender XDR retention + Entra audit logs |
| 9 — Email and Web Browser Protections | Defender for Office 365 (Strict) + SmartScreen |
| 10 — Malware Defenses | Defender + ASR + CFA |
| 11 — Data Recovery | BitLocker key escrow to Entra |
| 12 — Network Infrastructure Management | Firewall hardening |
| 13 — Network Monitoring and Defense | Defender XDR + MDA + MDI |
| 16 — Application Software Security | App Control (Audit) + MDA OAuth governance |
The CIS Microsoft Windows 11 Benchmark is the consensus-based hardening guide for Windows 11 endpoints. Level 1 covers practical hardening with minimal compatibility impact; Level 2 adds higher-friction safeguards for environments tolerating reduced functionality. Our endpoint baseline implements substantially all Level 1 recommendations.
Areas of Level 1 coverage
- Account and password policies (with documented exceptions for SMB-network operational realities)
- Local policies — security options (NTLM, anonymous access, network security)
- Windows Firewall with all profiles enabled
- Microsoft Defender Antivirus configuration
- Windows Update and Microsoft Store hardening
- SmartScreen and Internet Explorer / Edge legacy hardening
- Privacy and telemetry posture
Documented exceptions
Where the CIS benchmark conflicts with modern operational realities (for example, password complexity recommendations that conflict with NIST SP 800-63B current guidance, or firewall local-policy-merge rules that break DHCP on Public networks), we apply the more current Microsoft guidance with documented rationale.
CMMC 2.0 Level 2 (Advanced) maps directly to the 110 controls of NIST SP 800-171 Rev. 2, designed for protection of Controlled Unclassified Information (CUI) by DoD contractors and subcontractors. Our architecture substantially covers the technical practice families.
| Family | Implementation |
|---|---|
| 3.1 Access Control (22 practices) | Conditional Access + Strong Auth + MDI + UAC |
| 3.3 Audit and Accountability (9) | Defender XDR audit retention |
| 3.4 Configuration Management (9) | Intune baseline + Autopatch |
| 3.5 Identification and Authentication (11) | Strong Auth + MFA |
| 3.7 Maintenance (6) | Autopatch + Cloud Update |
| 3.8 Media Protection (9 — fully met) | Purview MIP + DLP + DLM + Endpoint device control |
| 3.13 System and Communications Protection (16) | Firewall + NTLM hardening + MDO + transport encryption |
| 3.14 System and Information Integrity (7) | Defender + ASR + CFA |
What we do not claim: CMMC certification. Level 2 certification requires assessment by a certified third-party assessor organization (C3PAO) with evidence of all 110 practices operating in steady state. Our technical implementation supports the practice base; formal assessment is a separate engagement.
The General Data Protection Regulation requires technical and organizational measures appropriate to the risks of processing personal data. Our Microsoft Purview deployment substantially implements the technical measures called for by GDPR Articles 5, 25, 30, 32, and 33.
| Article | Technical Measure |
|---|---|
| Art. 5 — Lawful processing, purpose & storage limitation | MIP labels (purpose) + DLM retention (storage limitation) |
| Art. 25 — Data protection by design and by default | MIP auto-labeling + DLP default-block policies |
| Art. 30 — Records of processing activities | MIP label inventory + Compliance Manager reports |
| Art. 32 — Security of processing | MIP encryption + DLP + Defender XDR + Strong Auth |
| Art. 33 — Breach notification (72-hour) | Defender XDR + DLP alerts |
| Art. 17 — Right to erasure | DLM disposition + eDiscovery |
Customers retain responsibility for lawful basis (Art. 6), data subject rights handling processes (Arts. 12–22), Data Protection Officer designation where applicable (Art. 37), and data processing agreements with third-party processors.
The California Consumer Privacy Act (and its CPRA amendment), Texas TDPSA, Virginia VCDPA, Colorado CPA, and similar state privacy laws share a common technical-foundation requirement: maintain reasonable security measures appropriate to the nature of the data processed. Our Purview deployment provides the technical foundation, including the data classification, DLP, retention, and disposal capabilities required by these statutes.
Subject-rights processing (right to know, right to delete, right to opt out of sale/sharing) requires organizational processes layered on top of the technical foundation.
The Federal Trade Commission Safeguards Rule applies to financial institutions and certain related businesses and was significantly updated in 2021/2023. Our architecture implements the technical safeguards specified in §314.4(c).
| Section | Implementation |
|---|---|
| §314.4(c)(1) Access controls | Conditional Access + Strong Auth + MDI |
| §314.4(c)(3) Encryption (at rest & in transit) | BitLocker + MIP + transport TLS |
| §314.4(c)(4) Multi-factor authentication | Strong Auth via Conditional Access |
| §314.4(c)(5) Monitoring & logging | Defender XDR + MDA + MDI |
| §314.4(c)(8) Disposal | Purview DLM disposition |
The New York State Department of Financial Services Cybersecurity Regulation (23 NYCRR 500) applies to entities supervised by NY DFS. Our architecture implements the relevant technical sections.
- §500.12 Multi-factor authentication — Strong Auth
- §500.13 Limitations on data retention — Purview DLM
- §500.14 Monitoring and training (technical) — Defender XDR + Attack Simulation Training capability
- §500.15 Encryption of nonpublic information — BitLocker + Purview MIP
Transparency: What We Claim and What We Don't
Honest framing matters. The phrasing we use below is precise on purpose — and it's the same phrasing we use in customer contracts, sales materials, and audit responses.
Compliance vs. Control Alignment
Frameworks like SOC 2, HIPAA, ISO 27001, and CMMC are not achieved by deploying technology alone. They each require organizational controls (policies, procedures, training, governance), administrative controls (risk assessment, incident response, vendor management), and — for some — independent audit attestation by qualified third parties.
What technology can do is implement the technical-control layer that frameworks specify. Our architecture does this comprehensively. What technology cannot do is replace the human, organizational, and audit components.
What we don't say
- "We are HIPAA compliant"
- "We are SOC 2 compliant"
- "We are ISO 27001 certified"
- "Our customers achieve compliance through our baseline"
- "HIPAA-ready"
What we do say
- "Our endpoint controls implement the HIPAA Security Rule §164.312 Technical Safeguards"
- "Our architecture satisfies the technical Common Criteria of SOC 2"
- "Our endpoint baseline aligns with ISO 27001:2022 Annex A.8 controls"
- "Our baseline provides the technical control foundation customers need to pursue compliance"
- "Microsoft Zero Trust + Defender XDR + Purview architecture aligned"
Continuous Improvement
Security baselines are living documents. Microsoft publishes new Windows and Microsoft 365 security baselines on a roughly twice-yearly cadence; the threat landscape changes daily. Our review and update process keeps the baseline current.
Each policy in our baseline is tagged with a version (currently Winter 2025). When Microsoft publishes a new Windows or Microsoft 365 security baseline, we evaluate the diff against our deployed posture, document any changes we adopt or reject, and roll the new version through pilot rings before production.
This versioning discipline gives customers a stable reference point — rather than a continuously-shifting policy that's hard to map to specific compliance assertions at a specific point in time.
Decisions to add, tighten, or relax a setting are driven by telemetry — not vendor marketing. We use Microsoft Defender XDR Advanced Hunting (Kusto Query Language) to identify whether a control is causing legitimate business friction or catching real threats, and we use Microsoft Purview Compliance Manager to quantify our framework alignment over time.
Where a recommendation from Microsoft's enterprise baseline conflicts with realistic small-business operations (e.g., the firewall AllowLocalPolicyMerge setting and home-network DHCP), we test, document, and apply calibrated exceptions rather than break user productivity.
The baseline described here is the minimum we deploy. Customers with elevated regulatory requirements (HIPAA Covered Entity, DFARS contractor, financial services) receive additional hardening: tighter password policy, App Control in Enforce mode with bespoke supplemental policies, separate device tiers for privileged users with required PIN at startup, and customer-scoped Compliance Manager assessments for the relevant framework.
Every additional vendor with kernel-level or system-level access to a managed endpoint represents a new trust boundary, a new supply-chain risk, and a new attack surface. The history of MSP-targeted ransomware operations against third-party RMM tools (which have, in published incidents, been used to deploy ransomware to thousands of downstream organizations) makes this a non-theoretical concern.
Our default is Microsoft-native tooling — not because Microsoft is uniquely secure, but because consolidating the trust boundary on the platform that operates the rest of our customers' productivity stack reduces the variance in security posture and the supply-chain attack surface compared to layering additional non-Microsoft agents onto every endpoint.
Concrete example: third-party application patching — historically the strongest argument for installing an RMM agent — is handled in our environment by a daily Intune Remediations script using Microsoft's native winget package manager and the Microsoft-published Microsoft.WinGet.Client PowerShell module. No additional agent is installed. See the Patch Management control for technical detail.