Palo Alto integration guide.

Verify EDL capacity

Check the total IP EDL capacity and available headroom on the actual firewall before adding Data-Shield. Include existing EDLs and any shared or virtual-system configuration. Use Objects → External Dynamic Lists → List Capacities.

show system state | match max-edl
request system external-list list-capacities

The first command is described in Palo Alto's platform-capacity article; the second is in the PAN-OS 11.1 command reference. A limit lower than the complete feed makes this deployment unsuitable without a supported capacity change. Do not silently truncate the feed.

Save a configuration snapshot. Verify DNS, time and the service route used for EDL retrieval. Preserve access through a trusted management path.

Create and authenticate the IP EDL

Standard

94,998 unique IPv4 addresses in this published snapshot.

https://raw.githubusercontent.com/duggytuxy/Data-Shield_IPv4_Blocklist/refs/heads/main/prod_data-shield_ipv4_blocklist.txt

Critical

104,852 unique IPv4 addresses in this published snapshot.

https://raw.githubusercontent.com/duggytuxy/Data-Shield_IPv4_Blocklist/refs/heads/main/prod_critical_data-shield_ipv4_blocklist.txt

Published 21 Oct 2026, 00:05 UTC. Check live counts and SHA-256.

1. Open Objects → External Dynamic Lists → Add. Name the object DataShieldStandard and select IP List.
2. Paste the Standard URL into Source. For Critical, use its URL and the name DataShieldCritical.
3. Select a Certificate Profile containing the trusted root and intermediate CAs needed to authenticate the actual HTTPS source. Obtain CA certificates through a trusted channel and verify them before import.
4. Leave client authentication disabled for these public feeds. Set Check for updates to hourly and use Test Source URL.
5. Save the object. If using Panorama or multiple virtual systems, verify the object scope and effective device configuration before committing.

Follow the vendor's EDL configuration procedure. A working download with certificate verification disabled is not the intended configuration.

Enforce an inbound source policy

1. In Policies → Security, add a rule named Data-Shield inbound.
2. Use your actual Internet-facing source zone, often named Untrust. Select the IP EDL as the Source Address.
3. Choose the protected destination zone and addresses. For destination NAT, confirm the platform's pre-NAT address and post-NAT zone matching requirements for your existing rules.
4. Use Drop as the action, log at session end and select applications and services broad enough to cover the intended inbound scope.
5. Position the rule above matching allow rules. Review the candidate configuration and commit it to the correct firewall or device group.

See EDL policy enforcement. This forwarding policy does not replace separate controls for the management interface or other services terminating on the firewall.

Verify entries and enforcement

Use these operational commands after committing. For a Critical object, substitute its name. The show command can produce extensive output.

request system external-list stats type ip name DataShieldStandard
request system external-list show type ip name DataShieldStandard

Check validity, authentication, imported count and the next retrieval. Inspect Monitor → Logs → System for EDL errors and Traffic logs for a new controlled inbound connection that matches the drop rule. Investigate skipped entries and capacity warnings.

To request an immediate retrieval, use Objects → External Dynamic Lists → Import Now and inspect the task result. This is the documented on-demand refresh.

request system external-list refresh type ip name DataShieldStandard

Monitor authentication and roll back

Alert on EDL authentication failures as well as stale downloads. Do not assume every failure keeps the last list enforced: authentication failure has distinct behavior documented by the vendor. Check the effective entries and policy state.

For rollback, disable the dedicated Data-Shield security rule and commit. Remove the EDL only after clearing its references. Keep the certificate profile if other objects use it. Shared whitelist changes take effect after a successful retrieval of the corrected publication.