Azure Data Factory Has Public Network Access: Why It Matters and How to Lock It Down

Azure Data Factory (ADF) sits at the center of a lot of data pipelines. It connects to storage accounts, SQL databases, Synapse, on-prem systems through self-hosted integration runtimes, and dozens of SaaS sources. That makes it a high-value target. When the factory's public network access is left on, its endpoints accept traffic from any IP on the internet, gated only by Azure AD authentication and whatever firewall rules you happen to have set.

This check looks at a single property on the factory: whether public network access is enabled. If it is, Lensix raises a finding so you can decide whether that exposure is intentional.

---

What this check detects

Every Data Factory has a publicNetworkAccess property. It accepts two values:

• Enabled — the factory's management and runtime endpoints are reachable from the public internet.
• Disabled — access is restricted to Private Endpoints within your virtual networks.

The check fails when publicNetworkAccess is set to Enabled. You can confirm the current state with a quick CLI call:

az datafactory show \
  --resource-group my-rg \
  --factory-name my-data-factory \
  --query "publicNetworkAccess" \
  --output tsv

---

Why it matters

A Data Factory is not just a workflow engine. It stores linked services, which often contain references to credentials, connection strings, and Key Vault secrets. It can reach private data stores through integration runtimes. If an attacker gains access to a factory, they can read those linked service definitions, trigger pipelines, and potentially exfiltrate or tamper with data as it moves.

Leaving the public endpoint open contributes to a few realistic problems:

• Broader attack surface. The endpoint is reachable from anywhere, so a leaked credential, a compromised service principal, or a token-theft phishing attack can be used from any network. There is no network-layer barrier slowing the attacker down.
• Credential blast radius. Service principals and managed identities tied to ADF frequently have access to multiple downstream resources. A single compromised identity hitting a public endpoint can pivot across your data platform.
• Data exfiltration paths. With public access on, traffic between ADF and some data stores can traverse public networks rather than staying on the Azure backbone, which both increases exposure and complicates egress controls.
• Compliance gaps. Frameworks like PCI DSS, HIPAA, and many internal data governance policies expect data services to be network-isolated. A publicly reachable factory is a common audit finding.

Network isolation does not replace identity controls. It layers on top of them. Defense in depth means an attacker has to defeat both the network boundary and authentication, not just one.

---

How to fix it

The fix has two parts. First, disable public network access. Second, set up Private Endpoints so your legitimate traffic still works. Doing them in the wrong order will break running pipelines, so plan accordingly.

Step 1: Create a Private Endpoint for the factory

Before you close the public door, build the private one. Create a Private Endpoint in the VNet your integration runtimes and management tooling use.

az network private-endpoint create \
  --name adf-private-endpoint \
  --resource-group my-rg \
  --vnet-name my-vnet \
  --subnet my-subnet \
  --private-connection-resource-id "/subscriptions/<sub-id>/resourceGroups/my-rg/providers/Microsoft.DataFactory/factories/my-data-factory" \
  --group-id dataFactory \
  --connection-name adf-connection

You will also want a second endpoint with the portal group ID if you need authoring access through the ADF Studio over the private network.

Step 2: Wire up Private DNS

Private Endpoints need DNS resolution to work. Create a Private DNS zone and link it to your VNet so the factory's FQDN resolves to the private IP.

az network private-dns zone create \
  --resource-group my-rg \
  --name "privatelink.datafactory.azure.net"

az network private-dns link vnet create \
  --resource-group my-rg \
  --zone-name "privatelink.datafactory.azure.net" \
  --name adf-dns-link \
  --virtual-network my-vnet \
  --registration-enabled false

Step 3: Disable public network access

Once the private path is verified, turn off public access.

az datafactory update \
  --resource-group my-rg \
  --factory-name my-data-factory \
  --public-network-access Disabled

To do the same in the portal: open the Data Factory resource, go to Networking, select the Public access tab, and set Public network access to Disabled. Then confirm your Private Endpoint connections under the Private access tab show a status of Approved.

Step 4: Verify

az datafactory show \
  --resource-group my-rg \
  --factory-name my-data-factory \
  --query "publicNetworkAccess" \
  --output tsv
# Expect: Disabled

Run a test pipeline and check that triggers fire and linked services connect. If something fails, it is almost always DNS or a missing Private Endpoint on a downstream data store rather than the factory itself.

---

Fix it as code

If you manage ADF with Terraform, set public_network_enabled to false on the factory and define the Private Endpoint alongside it.

resource "azurerm_data_factory" "main" {
  name                   = "my-data-factory"
  location               = azurerm_resource_group.main.location
  resource_group_name    = azurerm_resource_group.main.name
  public_network_enabled = false

  identity {
    type = "SystemAssigned"
  }
}

resource "azurerm_private_endpoint" "adf" {
  name                = "adf-private-endpoint"
  location            = azurerm_resource_group.main.location
  resource_group_name = azurerm_resource_group.main.name
  subnet_id           = azurerm_subnet.data.id

  private_service_connection {
    name                           = "adf-connection"
    private_connection_resource_id = azurerm_data_factory.main.id
    subresource_names              = ["dataFactory"]
    is_manual_connection           = false
  }

  private_dns_zone_group {
    name                 = "adf-dns"
    private_dns_zone_ids = [azurerm_private_dns_zone.adf.id]
  }
}

For Bicep, the equivalent property lives in the factory's properties block:

resource dataFactory 'Microsoft.DataFactory/factories@2018-06-01' = {
  name: 'my-data-factory'
  location: location
  identity: {
    type: 'SystemAssigned'
  }
  properties: {
    publicNetworkAccess: 'Disabled'
  }
}

---

How to prevent it from happening again

Manual fixes drift. A factory created next quarter by a different team will default to public access unless you put guardrails in place. Use Azure Policy to deny or audit factories with public access enabled.

Azure ships a built-in policy for this. Assign "Azure Data Factory should use private link" in Deny mode at the subscription or management group scope. If you prefer a custom definition, the rule is short:

{
  "if": {
    "allOf": [
      {
        "field": "type",
        "equals": "Microsoft.DataFactory/factories"
      },
      {
        "field": "Microsoft.DataFactory/factories/publicNetworkAccess",
        "equals": "Enabled"
      }
    ]
  },
  "then": {
    "effect": "deny"
  }
}

For teams shipping infrastructure through CI/CD, add a static check on your Terraform or Bicep before it reaches Azure. A Checkov or tfsec scan in the pipeline catches a misconfigured factory at pull-request time, which is far cheaper than catching it in production.

# Fail the build if any ADF allows public access
checkov -d ./infra --check CKV_AZURE_104

---

Best practices

• Default to private. Treat public network access as an exception that requires justification, not a default that requires opting out.
• Isolate the whole pipeline. Private-link the factory and every data store it touches. The chain is only as private as its most exposed hop.
• Use Managed Virtual Network integration runtimes. ADF's managed VNet keeps the Azure-hosted integration runtime inside a private network and supports managed Private Endpoints to data stores, which removes a lot of manual networking work.
• Scope identities tightly. Give the factory's managed identity only the permissions it needs on each downstream resource. Network isolation plus least privilege limits the damage if either control fails.
• Store secrets in Key Vault. Reference Key Vault from linked services instead of embedding credentials, and put a Private Endpoint on the vault too.
• Monitor and alert. Send ADF activity logs to a Log Analytics workspace and alert on changes to the publicNetworkAccess property so a regression does not sit unnoticed.

Disabling public network access is a small property change with an outsized effect. It moves your data factory off the open internet and onto your private network, where the rest of your data platform should already live. Pair it with policy enforcement and you turn a one-time fix into a standard that holds across every new environment.