<?xml version="1.0" encoding="UTF-8"?>
<rss xmlns:content="http://purl.org/rss/1.0/modules/content/" xmlns:dc="http://purl.org/dc/elements/1.1/" xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#" xmlns:taxo="http://purl.org/rss/1.0/modules/taxonomy/" version="2.0">
  <channel>
    <title>topic Secure Access ACL Best Practice in Secure Access Discussions</title>
    <link>https://community.cisco.com/t5/secure-access-discussions/secure-access-acl-best-practice/m-p/5372652#M160</link>
    <description>&lt;DIV class=""&gt;&amp;nbsp;&lt;/DIV&gt;&lt;DIV class=""&gt;&lt;DIV class=""&gt;&lt;DIV class=""&gt;&lt;P&gt;We are currently migrating from an on-prem FTD environment, where all traffic is backhauled through our data centers, to a more modern cloud-based security model using Cisco Secure Access. As part of this transition, we are leveraging the ZTA module to tunnel most non-excluded internet traffic to a Cisco data center. While ZTA is traditionally associated with private application access, this design was recommended directly by Cisco for our use case.&lt;/P&gt;&lt;P&gt;Our current ACL structure is based on Active Directory group membership, aligning access policies with a user’s specific role or “web level.” Each web level includes:&lt;/P&gt;&lt;UL&gt;&lt;LI&gt;&lt;P&gt;An&lt;SPAN&gt;&amp;nbsp;&lt;/SPAN&gt;&lt;STRONG&gt;Allow rule&lt;/STRONG&gt;&lt;SPAN&gt;&amp;nbsp;&lt;/SPAN&gt;for granular application/site access&lt;/P&gt;&lt;/LI&gt;&lt;LI&gt;&lt;P&gt;A&lt;SPAN&gt;&amp;nbsp;&lt;/SPAN&gt;&lt;STRONG&gt;Block rule&lt;/STRONG&gt;&lt;SPAN&gt;&amp;nbsp;&lt;/SPAN&gt;that enforces content category restrictions and general security controls via the associated security profile&lt;/P&gt;&lt;/LI&gt;&lt;/UL&gt;&lt;P&gt;The challenge we are encountering is related to unidentified users. Because the default action for internet-bound traffic is “Allow,” users who are not properly mapped to an AD group fall through to the implicit allow rule. To mitigate this, we have temporarily implemented a “Deny All” rule at the bottom of the ACL, but we recognize this is not considered best practice.&lt;/P&gt;&lt;P&gt;What would be the recommended approach for handling unidentified users and structuring ACL logic in a modern Secure Access deployment? Specifically, how can we ensure unidentified users are appropriately restricted without relying on a blanket deny-all rule at the bottom?&lt;/P&gt;&lt;P&gt;Any guidance on best practices for modern ACL design in this scenario would be greatly appreciated.&lt;/P&gt;&lt;/DIV&gt;&lt;/DIV&gt;&lt;/DIV&gt;</description>
    <pubDate>Wed, 25 Feb 2026 14:34:41 GMT</pubDate>
    <dc:creator>jaismith</dc:creator>
    <dc:date>2026-02-25T14:34:41Z</dc:date>
    <item>
      <title>Secure Access ACL Best Practice</title>
      <link>https://community.cisco.com/t5/secure-access-discussions/secure-access-acl-best-practice/m-p/5372652#M160</link>
      <description>&lt;DIV class=""&gt;&amp;nbsp;&lt;/DIV&gt;&lt;DIV class=""&gt;&lt;DIV class=""&gt;&lt;DIV class=""&gt;&lt;P&gt;We are currently migrating from an on-prem FTD environment, where all traffic is backhauled through our data centers, to a more modern cloud-based security model using Cisco Secure Access. As part of this transition, we are leveraging the ZTA module to tunnel most non-excluded internet traffic to a Cisco data center. While ZTA is traditionally associated with private application access, this design was recommended directly by Cisco for our use case.&lt;/P&gt;&lt;P&gt;Our current ACL structure is based on Active Directory group membership, aligning access policies with a user’s specific role or “web level.” Each web level includes:&lt;/P&gt;&lt;UL&gt;&lt;LI&gt;&lt;P&gt;An&lt;SPAN&gt;&amp;nbsp;&lt;/SPAN&gt;&lt;STRONG&gt;Allow rule&lt;/STRONG&gt;&lt;SPAN&gt;&amp;nbsp;&lt;/SPAN&gt;for granular application/site access&lt;/P&gt;&lt;/LI&gt;&lt;LI&gt;&lt;P&gt;A&lt;SPAN&gt;&amp;nbsp;&lt;/SPAN&gt;&lt;STRONG&gt;Block rule&lt;/STRONG&gt;&lt;SPAN&gt;&amp;nbsp;&lt;/SPAN&gt;that enforces content category restrictions and general security controls via the associated security profile&lt;/P&gt;&lt;/LI&gt;&lt;/UL&gt;&lt;P&gt;The challenge we are encountering is related to unidentified users. Because the default action for internet-bound traffic is “Allow,” users who are not properly mapped to an AD group fall through to the implicit allow rule. To mitigate this, we have temporarily implemented a “Deny All” rule at the bottom of the ACL, but we recognize this is not considered best practice.&lt;/P&gt;&lt;P&gt;What would be the recommended approach for handling unidentified users and structuring ACL logic in a modern Secure Access deployment? Specifically, how can we ensure unidentified users are appropriately restricted without relying on a blanket deny-all rule at the bottom?&lt;/P&gt;&lt;P&gt;Any guidance on best practices for modern ACL design in this scenario would be greatly appreciated.&lt;/P&gt;&lt;/DIV&gt;&lt;/DIV&gt;&lt;/DIV&gt;</description>
      <pubDate>Wed, 25 Feb 2026 14:34:41 GMT</pubDate>
      <guid>https://community.cisco.com/t5/secure-access-discussions/secure-access-acl-best-practice/m-p/5372652#M160</guid>
      <dc:creator>jaismith</dc:creator>
      <dc:date>2026-02-25T14:34:41Z</dc:date>
    </item>
  </channel>
</rss>

