How to Automate Entra Named Locations with PowerShell (2-5-3)

You can automate entra named locations powershell by defining approved corporate egress IP ranges in a version-controlled JSON file, then using Microsoft Graph PowerShell to create, update, validate, and log Entra ID named locations idempotently. For Saudi organizations addressing ECC 2:2024 control 2-5-3, the automation should support—not replace—network segmentation, firewall governance, approved change procedures, and evidence collection for Conditional Access location-based controls.

What can and cannot be automated for ECC 2-5-3?

Microsoft Entra named locations are useful for expressing trusted or blocked network boundaries in Conditional Access. For example, a Saudi organization may define the public NAT ranges used by its Riyadh headquarters, Jeddah branch, managed VPN gateways, and secure administration network. Conditional Access policies can then require stronger authentication outside those locations, block legacy access, or restrict access to sensitive Microsoft 365 applications from untrusted networks.

However, named locations do not create network segregation. They do not configure VLANs, firewall zones, DMZs, IPS/IDS, DNS security, wireless encryption, proxy filtering, or production-to-development isolation. These remain requirements under ECC 2-5-3 and must be enforced through network and security platforms such as firewalls, secure web gateways, wireless controllers, Azure networking, Microsoft Defender, DNS security services, and endpoint controls.

For a GRC engagement, treat the JSON file as a controlled technical standard: it should identify the location owner, business purpose, approved change reference, CIDR ranges, whether the range is trusted, and the review date. This creates a clear link between the ECC network security management policy, approved firewall or ISP changes, and the Entra configuration evidence.

How do you automate entra named locations powershell with Microsoft Graph?

The following walkthrough uses the Microsoft Graph PowerShell SDK rather than the retired Azure AD PowerShell modules. It manages an IP-based named location and is designed to be idempotent: running it repeatedly produces the required state instead of creating duplicate locations.

What permissions and prerequisites are required?

• Install the Microsoft.Graph.Identity.SignIns module on the automation runner.
• Create an Entra application registration for unattended execution.
• Grant application permission Policy.ReadWrite.ConditionalAccess and obtain tenant admin consent.
• Use a certificate stored in Azure Key Vault, Windows Certificate Store, or another approved secret-management platform; do not store client secrets in source control.
• Restrict repository write access and require approval for changes to trusted IP ranges.

The example below uses a certificate thumbprint. Before using it in production, the network owner should confirm that the addresses are stable public egress ranges, not internal RFC1918 addresses and not transient ISP ranges.

# Install once on the automation host
Install-Module Microsoft.Graph.Identity.SignIns -Scope AllUsers -Force

$TenantId              = "contoso-sa.onmicrosoft.com"
$ClientId              = "11111111-2222-3333-4444-555555555555"
$CertificateThumbprint = "A1B2C3D4E5F60718293A4B5C6D7E8F9012345678"

Connect-MgGraph `
  -TenantId $TenantId `
  -ClientId $ClientId `
  -CertificateThumbprint $CertificateThumbprint `
  -NoWelcome

What should the approved desired-state file contain?

Store the file below as named-locations.json in a protected repository. The change ticket and review date are not sent to Entra, but they are retained as governance evidence and included in job logs.

{
  "displayName": "SA-Riyadh-HQ-Internet-Egress",
  "isTrusted": true,
  "changeReference": "CHG-2026-01482",
  "owner": "Network Security Manager",
  "reviewDue": "2027-01-15",
  "ipRanges": [
    "185.12.44.0/24",
    "185.12.45.0/24",
    "212.138.91.128/25"
  ]
}

How does the idempotent PowerShell script work?

This script retrieves the existing location by display name, compares the approved CIDR ranges, and creates or updates the Microsoft Graph object only when a difference exists. It intentionally fails if more than one location has the same name because duplicate names make audit and rollback unreliable.

param(
    [Parameter(Mandatory)]
    [string]$ConfigPath = ".\named-locations.json"
)

$config = Get-Content -Path $ConfigPath -Raw | ConvertFrom-Json

$existing = Get-MgIdentityConditionalAccessNamedLocation -All |
    Where-Object {
        $_.AdditionalProperties["@odata.type"] -eq "#microsoft.graph.ipNamedLocation" -and
        $_.DisplayName -eq $config.displayName
    }

if (@($existing).Count -gt 1) {
    throw "More than one named location uses '$($config.displayName)'. Resolve duplicates before continuing."
}

$ipRanges = @(
    foreach ($cidr in $config.ipRanges) {
        @{
            "@odata.type" = "#microsoft.graph.iPv4CidrRange"
            "cidrAddress" = $cidr
        }
    }
)

$body = @{
    "@odata.type" = "#microsoft.graph.ipNamedLocation"
    "displayName" = $config.displayName
    "isTrusted"   = [bool]$config.isTrusted
    "ipRanges"    = $ipRanges
}

if (-not $existing) {
    $result = New-MgIdentityConditionalAccessNamedLocation -BodyParameter $body
    Write-Output "Created named location: $($result.Id)"
}
else {
    $currentRanges = @(
        $existing.IpRanges | ForEach-Object { $_.CidrAddress } | Sort-Object
    )
    $desiredRanges = @($config.ipRanges | Sort-Object)

    $rangesMatch = ($currentRanges -join ",") -eq ($desiredRanges -join ",")
    $trustMatch = [bool]$existing.IsTrusted -eq [bool]$config.isTrusted

    if ($rangesMatch -and $trustMatch) {
        Write-Output "No change required for $($config.displayName)."
    }
    else {
        Update-MgIdentityConditionalAccessNamedLocation `
          -NamedLocationId $existing.Id `
          -BodyParameter $body

        Write-Output "Updated named location: $($existing.Id)"
    }
}

Write-Output "Change reference: $($config.changeReference)"
Write-Output "Owner: $($config.owner)"
Write-Output "Review due: $($config.reviewDue)"

Disconnect-MgGraph

A practical control point is to use this script only for named-location objects. Keep Conditional Access policy changes in a separate workflow, with impact analysis and a staged deployment process. A mistakenly trusted range can weaken access controls across Microsoft 365, especially where policies exclude trusted locations from MFA or device requirements.

How should this run in CI/CD or scheduled jobs?

For most Saudi clients, use a protected Azure DevOps pipeline, GitHub Actions workflow with a self-hosted runner, or Azure Automation Hybrid Runbook Worker. A self-hosted runner is often preferred when certificates must remain in a controlled environment and the organization requires evidence that changes originated from an approved administrative network.

1. A network engineer submits a pull request changing named-locations.json.
2. The pull request must reference an approved change record and be approved by the network security owner and the GRC or cybersecurity representative.
3. A validation job checks CIDR syntax, rejects private address ranges, and confirms the review date is valid.
4. The deployment job authenticates using the certificate-based service principal and runs the idempotent script.
5. The job archives the JSON file, execution output, Graph object ID, approver details, and change reference in the evidence repository.
6. A scheduled monthly read-only job compares Entra configuration against the approved repository and reports drift.

This approach to Entra named location automation makes evidence collection easier for ECC 2-5-3 reviews: the approved baseline demonstrates intended configuration, while job logs and exported Graph results demonstrate implementation.

Which monitoring and alerting hooks should be added?

Enable Entra audit log retention and forward logs to Microsoft Sentinel or another approved SIEM. Monitor directory audit events relating to Conditional Access named locations, Conditional Access policy updates, service principal sign-ins, and consent or credential changes for the automation application.

• Alert when a named location is created, deleted, or modified outside the approved automation service principal.
• Alert when a trusted location gains new CIDR ranges or its isTrusted setting changes.
• Alert when the automation service principal authenticates from an unexpected workload, subscription, or country.
• Run a daily drift report comparing Graph results to the repository baseline.
• Send failed deployment notifications to the change owner, SOC, and GRC evidence mailbox.

For ECC evidence, retain a screenshot or exported report showing the named location configuration, the associated Conditional Access policy where applicable, the approved change record, and the corresponding network diagram showing the corporate egress point. Do not present named locations as proof of firewall segmentation; pair the Entra evidence with firewall, VLAN, DMZ, or cloud-network evidence relevant to the applicable sub-control.

How should failures and unsafe changes be handled?

Failure handling should be conservative. The script must stop before making changes if authentication fails, duplicate display names exist, CIDR values are invalid, the required approval reference is missing, or the Graph API returns an error. Never continue by deleting and recreating a location automatically, because Conditional Access policies may reference its object ID and an unplanned deletion can alter access outcomes.

Before every update, export the existing named location object to a timestamped JSON file in the evidence store. If an approved rollback is required, use that export to restore the prior ranges and trusted setting through the same controlled pipeline. For high-impact locations, run the change first in a test tenant where available, then schedule production execution during an approved change window with a conditional access administrator available to validate sign-in behavior.

As your next step, build a controlled named-location inventory from your Saudi organization’s approved public egress ranges and map each entry to its ECC 2-5-3 change, owner, network diagram, and review date.