Why the Microsoft Security Stack Has No Visibility Here

Microsoft Defender for Endpoint operates on a host-based agent model. It requires a supported OS, an enrolled device, and an active MDE sensor. Network appliances — Palo Alto NGFWs, Fortinet FortiGates, Cisco ASAs, Check Point gateways — run proprietary operating systems. They do not enroll in Intune. They do not report to Defender. They do not appear in the Entra ID device inventory.

Entra Conditional Access evaluates identity signals at authentication time. If the management plane of your firewall does not authenticate through Entra ID — and the overwhelming majority do not — Conditional Access has no surface to evaluate. There is no token, no session, no policy applied.

Microsoft Sentinel can ingest syslog and CEF-formatted logs from network appliances through the Common Event Format (CEF) connector or vendor-specific data connectors. But ingestion is not detection. If the appliance is not configured to forward authentication events, configuration change events, and privileged session events to your Log Analytics workspace, Sentinel sees nothing. Many deployments forward only traffic logs, leaving the management plane completely dark.

This is the structural problem. The management plane operates in a parallel authentication universe. It has its own local user database, its own session model, and its own access controls — none of which are federated into your identity governance framework.

The Lateral Movement Path That Bypasses Endpoint Controls

When an attacker gains unauthenticated or weakly authenticated root access to a firewall management plane, the immediate capability set is significant. They can modify NAT rules to redirect traffic. They can disable inspection policies on specific segments. They can add static routes that bypass security zones. They can extract VPN pre-shared keys or certificate private keys stored on the device.

None of these actions generate events in Microsoft Defender XDR. None of them trigger Intune compliance alerts. None of them appear in Entra ID sign-in logs.

The lateral movement path from firewall management plane to endpoint control plane is well-documented in adversary tradecraft. An attacker who controls the firewall can manipulate DNS responses for internal clients, intercept unencrypted management traffic from other appliances, or pivot through site-to-site VPN tunnels into network segments that are otherwise isolated. From there, reaching an Intune-managed endpoint — or the Intune service itself through a compromised admin workstation — becomes a sequenced, low-noise operation.

Microsoft Defender for Identity monitors domain controller traffic and can detect certain lateral movement patterns, but it operates on Kerberos and NTLM authentication events. A pivot that originates from a network appliance and moves through infrastructure-level access — SSH, API calls, management protocols — does not generate the authentication artifacts MDI is designed to detect.

What Sentinel Can See — and What It Cannot

If your firewall vendor has a Microsoft Sentinel data connector — Palo Alto Networks, Fortinet, Check Point, and Cisco all have published connectors as of September 2026 — you have a starting point. The connectors normalize vendor log formats into the CommonSecurityLog table in your Log Analytics workspace.

The problem is scope. Most connector configurations default to forwarding firewall traffic logs. Management plane events — administrator logins, configuration commits, privilege escalations, failed authentication attempts — require explicit configuration on the appliance side to forward those event categories.

The following KQL query identifies successful root-level authentication events ingested from network appliances, assuming your appliance is forwarding management authentication events to Sentinel:

CommonSecurityLog
| where DeviceVendor in ("Palo Alto Networks", "Fortinet", "Check Point")
| where Activity has_any ("login", "authentication", "admin")
| where DestinationUserName has_any ("root", "admin", "superuser")
| where DeviceAction == "success"
| summarize SessionCount = count() by DeviceVendor, DeviceProduct, DestinationUserName, SourceIP, bin(TimeGenerated, 1h)
| order by SessionCount desc

If this query returns no results, you have one of two problems: your appliances are not forwarding management authentication events, or they are not forwarding any logs at all. Both are equally dangerous from a detection standpoint.

For appliances forwarding to a syslog collector rather than directly to the CEF connector, use the Syslog table and parse vendor-specific fields manually. This is operationally expensive but necessary for appliances without native Sentinel connectors.

Auditing the Management Plane Attack Surface

Before implementing controls, you need an accurate inventory of what your management plane exposure actually looks like. This means answering four questions for every network appliance in scope:

What authentication methods are enabled? SSH with password authentication, local web console with default credentials, RADIUS integration, TACACS+ integration, certificate-based authentication — each carries a different risk profile. Password authentication over SSH with no MFA is the highest-risk configuration.

What accounts exist on the device? Local accounts that were created during initial deployment and never reviewed are a persistent risk. Many appliances ship with vendor service accounts that are documented in public knowledge bases.

What management interfaces are exposed, and to which network segments? A management interface reachable from the general corporate network — rather than a dedicated out-of-band management VLAN — dramatically expands the attack surface.

Are configuration changes logged, and are those logs forwarded off-device? Logs stored only on the appliance itself can be cleared by an attacker who has root access. Off-device log forwarding is a prerequisite for forensic integrity.

The following PowerShell script queries Windows Security event logs on a jump server or bastion host used to access firewall management interfaces, identifying failed authentication attempts that may indicate brute-force activity against management plane credentials:

$StartTime = (Get-Date).AddDays(-7)

Get-WinEvent -FilterHashtable @{
    LogName   = 'Security'
    Id        = 4625
    StartTime = $StartTime
} | ForEach-Object {
    $xml = [xml]$_.ToXml()
    $data = $xml.Event.EventData.Data
    [PSCustomObject]@{
        TimeGenerated    = $_.TimeCreated
        TargetUserName   = ($data | Where-Object { $_.Name -eq 'TargetUserName' }).'#text'
        WorkstationName  = ($data | Where-Object { $_.Name -eq 'WorkstationName' }).'#text'
        IpAddress        = ($data | Where-Object { $_.Name -eq 'IpAddress' }).'#text'
        FailureReason    = ($data | Where-Object { $_.Name -eq 'FailureReason' }).'#text'
    }
} | Where-Object { $_.TargetUserName -ne '-' } |
Sort-Object TimeGenerated -Descending |
Export-Csv -Path ".\FailedAuthAttempts_$(Get-Date -Format 'yyyyMMdd').csv" -NoTypeInformation

Write-Host "Export complete. Review FailedAuthAttempts CSV for brute-force indicators."

This script produces a time-stamped CSV of failed authentication events from the past seven days, filtered to exclude system-generated noise. Review the IpAddress field for source IPs that do not belong to your designated management network range — any external or unexpected internal IP is an immediate investigation priority.

Governance Gaps That Compliance Frameworks Expose

CIS Controls v8, Control 4.1 requires that all administrative access to enterprise assets use multi-factor authentication. Network appliances are enterprise assets. If your firewall management plane accepts single-factor SSH password authentication, you are out of conformance with CIS v8 4.1 regardless of how well-configured your Entra MFA policies are for user endpoints.

CIS Controls v8, Control 8.2 requires that audit logs be collected on all enterprise assets. If your firewall is not forwarding management plane events to a centralized logging solution, you are not meeting this control — and you will not be able to demonstrate compliance during an audit or reconstruct an incident timeline after a breach.

SOC 2 Trust Services Criteria CC6.1 requires logical access controls that restrict access to information assets. An appliance with a local root account that has never been rotated, accessible over SSH from the corporate network, does not meet CC6.1. The auditor will ask for evidence of access reviews, credential rotation schedules, and MFA enforcement. If those controls do not exist on the management plane, the finding will be material.

Microsoft's Zero Trust architecture is built on the principle of explicit verification for every access request. The management plane of a network appliance that authenticates through a local database — with no integration into Entra ID, no Conditional Access policy, and no MFA requirement — is a Zero Trust exception that undermines the model at the network layer, precisely where Zero Trust is supposed to be most rigorous.

The governance implication is not just a compliance checkbox problem. It is a liability problem. If an attacker uses unauthenticated root access on a firewall management plane to pivot into your environment and exfiltrate data, the forensic question will be: what controls existed on that management plane, and when were they last reviewed? If the answer is "none" and "never," the organization's legal and regulatory exposure is significant.

Closing the Gap: Specific Controls in Priority Order

First: Integrate management plane authentication with a centralized identity provider. For appliances that support RADIUS or TACACS+, deploy Microsoft Network Policy Server (NPS) with Entra MFA integration using the NPS extension. This routes management plane authentication through Entra ID, enabling MFA enforcement and generating sign-in events that appear in Entra ID logs and can be ingested by Sentinel. This is the highest-impact single control available.

Second: Restrict management interface reachability to a dedicated out-of-band management VLAN. No management interface should be reachable from the general corporate network, the internet, or any segment that hosts user endpoints. Access to the management VLAN should require a privileged access workstation (PAW) that is Intune-enrolled, Entra-joined, and subject to Conditional Access policies requiring compliant device status and MFA.

Third: Disable all default vendor accounts and rotate all local credentials on a defined schedule. Document every local account on every appliance in your privileged access management (PAM) solution — Microsoft Entra Permissions Management or a third-party PAM tool. Rotate credentials on a schedule aligned to your organization's privileged account policy, typically 90 days or less.

Fourth: Configure the appliance to forward management plane events to Sentinel. This includes administrator authentication events (success and failure), configuration commit events, privilege escalation events, and session termination events. Validate forwarding with the KQL query in the previous section. Set up Microsoft Sentinel Analytics rules to alert on root-level successful authentications from unexpected source IPs and on configuration changes outside defined maintenance windows.

Fifth: Conduct quarterly access reviews of all local accounts on network appliances. This review should be documented, assigned to a named owner, and tracked in your governance, risk, and compliance (GRC) platform. Any account that cannot be attributed to a current employee or service function should be disabled immediately.