Why Satellite Terminals Break the Assumed Architecture

The standard enterprise security architecture assumes that internet-bound traffic from managed devices flows through a controlled egress point — whether that is a Zscaler node, a Microsoft Entra Private Access connector, or a traditional firewall with TLS inspection. Conditional Access policies, Defender for Endpoint network protection, and Microsoft Purview DLP enforcement all depend on this assumption holding.

Satellite ground terminals violate it structurally. A Starlink Business terminal, for example, establishes a direct Layer 3 path to the internet via low-earth orbit relay. There is no corporate DNS resolver in that path. There is no proxy enforcing Safe Links or Safe Attachments inspection. There is no network sensor feeding telemetry into Microsoft Sentinel. The device is enrolled in Intune, it may be fully compliant by every policy check, and it is still operating in a security blind spot the moment it routes through that terminal.

This distinction matters because most governance frameworks — and most security teams — conflate the two. A device that passes all compliance checks is not automatically safe. If it is exfiltrating data over a satellite link that bypasses Microsoft Purview endpoint DLP, the compliance badge is irrelevant.

The Specific Gaps Satellite Paths Create in Microsoft 365 Tenants

When a managed device connects to Exchange Online, SharePoint, or Teams through a satellite terminal rather than a corporate egress point, several Microsoft 365 security controls either degrade or fail entirely.

Microsoft Defender for Cloud Apps relies on network-level signals and proxy log ingestion to detect shadow IT and anomalous OAuth activity. A satellite path that does not route through a Cloud App Security proxy or a Defender-integrated secure web gateway produces no log data for that session. The MCAS activity log shows the authentication event from Entra ID, but the network behavior around it is invisible.

Microsoft Purview Communication Compliance and Insider Risk Management both depend on activity signals. When a user on a satellite link downloads a large SharePoint library and copies it to a USB drive, the endpoint DLP policy may fire — but only if the device has the Purview client active and the policy scope includes removable media. If the policy was scoped to network egress monitoring through a corporate proxy, it does not apply to the satellite path.

Entra ID Conditional Access location-based policies are particularly vulnerable. Named locations in Conditional Access are defined by IP ranges. Satellite terminal egress IPs are assigned dynamically by the provider and are not predictable. A policy that blocks access from non-corporate IP ranges will block the satellite user entirely — which is the correct security outcome, but one that most organizations have not deliberately designed for. The more common outcome is that location-based policies were never configured, and the satellite path is indistinguishable from any other internet connection.

Operational Impact: What Changes When a Terminal Goes Live

The operational challenge is not just architectural — it is procedural. Satellite terminals are frequently deployed by facilities teams, operations managers, or field engineers who have no interaction with the security or endpoint management teams. By the time the terminal is live and devices are connecting through it, it may not appear in any asset register.

Discovering Terminals Already in Your Environment

The first operational step is detection. Microsoft Defender for Endpoint network telemetry can surface satellite provider IP ranges in the DeviceNetworkEvents table in Microsoft 365 Defender Advanced Hunting. Starlink, Viasat, and Hughes Network Systems each have published ASN ranges that can be used as filter criteria.

// Identify devices communicating through known satellite provider ASNs
// Replace ASN values with current published ranges for your target providers
DeviceNetworkEvents
| where RemoteIPType == "Public"
| where RemoteIP matches regex @"^(98\.97\.|100\.64\.|192\.168\.100\.)"
    or RemoteUrl has_any ("starlink.com", "viasat.com", "hughes.net")
| summarize
    ConnectionCount = count(),
    UniqueDevices = dcount(DeviceId),
    FirstSeen = min(Timestamp),
    LastSeen = max(Timestamp)
    by RemoteUrl, RemoteIP
| order by ConnectionCount desc

This query is a starting point, not a complete solution. Satellite providers route through multiple upstream carriers, and their egress IP ranges change. A more durable detection approach combines this query with Microsoft Sentinel watchlists that are updated against published BGP route data for known satellite ASNs.

Enforcing Compliance Regardless of Network Path

Intune compliance policies must be reviewed with satellite paths explicitly in mind. The key question for each policy rule is: does this rule depend on the device being on a specific network, or does it enforce a device-state condition that holds regardless of connectivity path?

Device-state conditions — BitLocker encryption status, OS patch level, Defender antivirus signature currency, certificate presence — hold regardless of network path and should be the primary compliance enforcement mechanism for devices that may connect via satellite.

Connect-MgGraph -Scopes "DeviceManagementManagedDevices.Read.All"

$devices = Get-MgDeviceManagementManagedDevice -All -Select "deviceName,complianceState,lastSyncDateTime,operatingSystem"

$devices | Where-Object { $_.ComplianceState -ne "compliant" } |
    Select-Object DeviceName, ComplianceState, LastSyncDateTime, OperatingSystem |
    Sort-Object LastSyncDateTime |
    Export-Csv -Path ".\NonCompliantDevices_$(Get-Date -Format yyyyMMdd).csv" -NoTypeInformation

Write-Host "Non-compliant device export complete."

Run this export on a scheduled basis and cross-reference against your satellite terminal asset inventory. Devices that are non-compliant and last synced from a satellite egress IP should be treated as high-priority remediation targets.

Threat Detection for Satellite-Adjacent Behavior

Microsoft Defender for Endpoint behavioral detection does not change based on the network path — endpoint telemetry is uploaded to the Defender backend regardless of how the device reaches the internet. This is one of the genuine architectural advantages of an endpoint-native detection model. However, network-level detections that depend on proxy or firewall log ingestion will have gaps.

Supplement endpoint telemetry with a KQL rule in Microsoft Sentinel that flags devices showing high-volume outbound data transfer events correlated with known satellite provider domains:

// Flag high-volume outbound transfers from devices with satellite connectivity indicators
DeviceNetworkEvents
| where ActionType == "ConnectionSuccess"
| where RemoteUrl has_any ("starlink.com", "viasat.com", "hughes.net")
| join kind=inner (
    DeviceFileEvents
    | where ActionType in ("FileCreated", "FileCopied")
    | where FolderPath has_any ("\\Removable", "D:\\", "E:\\")
    | summarize FileEventCount = count() by DeviceId, bin(Timestamp, 1h)
) on DeviceId
| where FileEventCount > 20
| project Timestamp, DeviceName, RemoteUrl, FileEventCount
| order by FileEventCount desc

This correlation surfaces the specific insider risk scenario where a satellite path is being used as a covert exfiltration channel — a scenario that neither endpoint DLP nor MCAS would catch without this cross-signal join.

Governance Considerations for Satellite-Connected Infrastructure

Satellite terminals create compliance gaps that are not hypothetical. Under SOC 2 Type II, auditors expect documented evidence that all network egress points are inventoried and subject to monitoring controls. A satellite terminal that was deployed without security review and is not present in the asset register is a finding — not a risk acceptance, because the risk was never formally acknowledged.

Under FedRAMP Moderate and High baselines, the SC-7 (Boundary Protection) control family requires that all external boundary communications be monitored and controlled. A satellite terminal that routes around the documented boundary architecture is a direct SC-7 gap. Agencies and contractors operating under FedRAMP authorization need to treat undocumented satellite terminals as a potential authorization boundary violation, not just a security risk.

Zero Trust alignment requires revisiting the network assumption entirely. Microsoft's Zero Trust guidance, documented in the Microsoft Zero Trust Deployment Center, explicitly calls for treating every network as untrusted. Satellite paths are a concrete test of whether that principle has been operationalized or merely stated. If your Conditional Access policies, Defender for Endpoint configuration, and Purview DLP rules all hold regardless of which network the device is on, satellite terminals are a manageable risk. If any of those controls depend on the device being on a trusted network, you have a gap.

Connect-MgGraph -Scopes "Policy.Read.All"

$caPolicies = Get-MgIdentityConditionalAccessPolicy -All

$locationDependentPolicies = $caPolicies | Where-Object {
    $_.Conditions.Locations -ne $null -and
    ($_.Conditions.Locations.IncludeLocations.Count -gt 0 -or
     $_.Conditions.Locations.ExcludeLocations.Count -gt 0)
}

$locationDependentPolicies | Select-Object DisplayName, State |
    ForEach-Object {
        Write-Host "Policy: $($_.DisplayName) | State: $($_.State)"
    }

Review each policy returned by this script. For any policy that grants access based on a named location (corporate IP range), determine whether a satellite-connected device would be blocked or inadvertently permitted. Policies that block non-named-location access are correctly configured for this threat. Policies that grant access based on named location membership need a parallel rule that enforces device compliance as the primary gate.

Recommendations for Closing the Gap

The following steps address the satellite terminal threat vector in priority order, based on the controls most likely to be missing in a typical enterprise Intune deployment.

Establish a satellite terminal asset register. Work with facilities, operations, and procurement to identify all deployed terminals. Include terminal serial number, physical location, associated network segment, and the identity of the business owner who approved deployment. This register feeds both your SOC 2 asset inventory and your FedRAMP boundary documentation.

Define a Conditional Access policy that treats satellite egress IPs as untrusted networks. Since satellite egress IPs are dynamic, the practical implementation is to require device compliance and MFA for all access that does not originate from a known corporate named location. This is the correct Zero Trust posture regardless of satellite terminals — but satellite terminals make it urgent.

Deploy Microsoft Entra Private Access for any application that should not be reachable from an arbitrary internet path. Private Access replaces VPN for application-level access and enforces Conditional Access at the application layer, not the network layer. A device on a satellite link can still reach internal applications through Private Access — but only if it passes the Conditional Access policy, which includes compliance state and MFA.

Configure Microsoft Purview Endpoint DLP policies that are scoped to device state, not network location. DLP rules that trigger on removable media copy, clipboard transfer, or print operations apply regardless of the network path the device is using. Network-scoped DLP rules — those that inspect egress through a proxy — do not apply to satellite paths and should be supplemented with endpoint-scoped equivalents.

Add satellite provider ASN watchlists to Microsoft Sentinel and create analytics rules that alert on first-time device connections through satellite egress IPs. Treat the first connection as a discovery event, not necessarily a threat — but require that the terminal be registered in the asset register within 48 hours or the device be quarantined via Intune.