Table of Contents

What is a Dynamic Access Control List (dACL)?

A Dynamic Access Control List (dACL), also called a Downloadable ACL, is a network security policy that is centrally defined on a RADIUS or NAC policy server and dynamically pushed down to switches, routers, or wireless access points at the moment a user or device authenticates to the network. Rather than hardcoding access rules on individual network devices, dACLs allow banks and financial institutions, hotels & education campuses to enforce precise, role-based traffic permissions per user, per device, and per session—automatically and at scale across all branches, ATMs, and data centers.

See how IO by HFCL implements dACL-based policy enforcement in banking networks

How do dACLs Work? 

Centralized Policy Definition

In a traditional network, access control lists are manually configured on each switch or access point individually—a time-consuming and error-prone process for large banking networks spanning hundreds of branches. dACLs eliminate this by centralizing policy definition: network administrators define ACL rules once on a central policy server such as Cisco ISE or any RADIUS-compatible NAC platform, specifying exactly which traffic a given user role or device type is permitted or denied.

Authentication and ACL Delivery via RADIUS

When a device connects and authenticates via 802.1X or MAC-based authentication, the RADIUS server processes the authentication request and returns an Access-Accept message that either includes the ACL rules directly (inline) or references the name of the dACL the network device should retrieve. The switch or wireless controller then downloads those specific ACL rules from the policy server and applies them to the port or wireless session of that particular endpoint. The result is that each connected device receives a bespoke traffic policy—a bank teller's laptop gets rules permitting access to core banking and CRM but blocking internet browsing, while an ATM gets rules permitting only connections to payment servers and denying all other traffic.

Session-Level Enforcement and CoA Integration

When a session ends, the dACL is cleared from the device, ensuring that policies do not persist beyond the session or contaminate access for the next user connecting on the same port. dACLs also integrate tightly with Change of Authorization (CoA): if a device's compliance status changes mid-session, the policy server can push a new dACL to immediately restrict or revoke access without disconnecting the session.

Why dACL matters for BFSI?

Operational Scale and Consistency

BFSI institutions manage enormously diverse endpoint populations—tellers, loan officers, back-office staff, ATMs, IP cameras, POS terminals, contractor laptops, and guest devices—all connecting across hundreds of geographically distributed branches and data centers. Maintaining manually configured, device-specific ACLs across this scale is operationally impractical and creates significant security risk from misconfiguration and inconsistency. dACLs resolve this by ensuring that the same correctly defined policy is enforced uniformly from a single source of truth, regardless of which branch or which port a device connects to.

Regulatory Compliance: PCI DSS and RBI IT Framework

From a regulatory and compliance standpoint, PCI DSS requires strict segmentation of cardholder data environments and precise access controls that limit which systems can communicate with payment infrastructure. dACLs make this enforcement automated and auditable: every access decision is driven by a centrally managed policy, with detailed logs of which rules were applied to which devices at what times—exactly the kind of documentation that satisfies RBI IT Framework audits, internal risk reviews, and external regulatory examinations. 

Zero Trust Enforcement at the Network Layer

For Zero Trust architectures, dACLs are a core enforcement mechanism that operationalizes the principle of least-privilege access at the network layer.

Common BFSI use cases of dACLs

Role-based branch access enforcement:

When a branch manager authenticates, the RADIUS server pushes a dACL permitting access to core banking, financial reporting, and management dashboards, while blocking peer-to-peer traffic and unauthorized cloud services—ensuring role-appropriate access without manual configuration on each branch switch.

ATM and payment terminal isolation:

ATMs and POS terminals receive dACLs permitting traffic only to specific payment processing servers and transaction APIs, with all other destinations explicitly denied, creating compliant PCI DSS segmentation that is automatically enforced at the moment the device authenticates.

Contractor and vendor access control

Third-party engineers and vendors connecting to branch or data center networks receive restrictive dACLs that permit access only to specific maintenance systems or diagnostic tools for a defined period, automatically expiring when the session ends without leaving residual access rules on the network device.

Quarantine enforcement for non-compliant endpoints:

Devices failing security posture checks—missing antivirus updates, expired certificates, or disabled firewalls—receive a quarantine dACL permitting traffic only to remediation servers until compliance is restored, protecting the broader banking network without requiring manual intervention.

Cloud migration and hybrid environments

As banks migrate workloads to private and hybrid cloud environments, dACLs enforce consistent access segmentation between on-premises branch networks and cloud-hosted banking applications, ensuring that only authorized endpoints and services can reach sensitive cloud workloads.

Simple analogy of dACLs

Think of a bank's traditional ACL configuration like giving every security guard at every branch a printed rulebook—each guard needs to be individually updated every time the rules change, and mistakes are inevitable across hundreds of locations. dACLs are like replacing those printed rulebooks with a live connection to headquarters: the moment a staff member badges in, headquarters automatically sends the exact rules applicable to that person's role directly to the guard at that door—no manual updates, no inconsistencies, and the rules disappear the moment the person leaves.

Key takeaway 

Dynamic Access Control Lists give BFSI institutions the ability to enforce precise, role-based, least-privilege network access policies automatically at scale—centrally defined, dynamically applied at authentication, and instantly updatable—making them a foundational enforcement mechanism for Zero Trust architectures, PCI DSS compliance, and secure banking network operations across distributed branch and digital infrastructure.

Explore HFCL’ s Banking Network Solutions

What is a dACL in networking?

A Dynamic Access Control List (dACL), or Downloadable ACL, is a traffic permission policy centrally defined on a RADIUS or NAC server and automatically pushed to a switch or access point when a device authenticates. It controls exactly which network resources a device or user can reach during that specific session.

How is a dACL different from a standard ACL?

A standard ACL is manually configured directly on each network device and remains static until an administrator changes it. A dACL is defined once on a central policy server and applied dynamically per session per device at the moment of authentication, ensuring consistent, role-accurate policies across all locations without manual device-level configuration.

How does dACL work with RADIUS?

When a device connects and authenticates via 802.1X, the RADIUS server returns an Access-Accept response either containing the ACL rules directly or referencing the name of a stored dACL. The network switch or wireless controller then downloads and applies those rules to that specific port or wireless session, creating a per-user, per-device traffic policy.

Why do banks use Dynamic Access Control Lists?

Banks use dACLs to enforce least-privilege access across large, distributed branch networks without manually configuring ACLs on hundreds of individual switches. A teller workstation automatically receives rules permitting core banking and CRM access, an ATM receives rules allowing only payment server communication, and a contractor laptop receives restricted, time-bound access—all enforced consistently from a single central policy server.

Is dACL required for PCI DSS compliance?

dACLs are not explicitly mandated by name in PCI DSS, but they directly implement several PCI DSS requirements—particularly around network segmentation, least-privilege access control, and restricting inbound and outbound traffic to cardholder data environments. Using dACLs automates and centralizes enforcement of these controls, simplifying PCI DSS audits and reducing the risk of misconfiguration across branch networks.

How does dACL relate to Zero Trust?

dACLs are a core enforcement mechanism within a Zero Trust architecture. Zero Trust requires that every device and user receive only the minimum access needed for their specific role, continuously re-evaluated. dACLs operationalize this at the network layer: each authenticated session receives a bespoke, role-specific traffic policy, and when device posture changes, CoA can push a new dACL instantly to restrict or revoke access.

What is the difference between dACL and VLAN assignment?

VLAN assignment places a device into a network segment defined by its role or compliance status—it controls which broadcast domain the device belongs to. A dACL goes further by specifying exactly which IP addresses, protocols, and ports that device can communicate with within and beyond its VLAN. Banks typically use both together: VLAN for broad segmentation and dACL for precise traffic control within that segment.