# Cisco advanced phishing protection > Understand Cisco Advanced Phishing Protection, its gateway sensor flow, current support limits, and the tenant evidence needed to verify coverage. Cisco Advanced Phishing Protection is Cisco's cloud service for business-email-compromise and phishing detection based on identity-deception signals. In Cisco's documented gateway integration, a registered email gateway acts as a sensor and forwards message metadata for cloud analysis. Whether it protects a particular recipient depends on the release, license, active service, sensor mode, configured policy, recipient scope, and message evidence. It is not a generic guarantee that every phishing message is blocked. ## Quick takeaways - Cisco documents the service as a BEC and phishing-detection capability focused on identity-deception threats. - A Cisco email gateway can operate as a sensor that forwards message metadata to the cloud service for analysis. - The documented workflow requires licensing, account activation, sensor registration, and policy configuration. - Cisco's AsyncOS 14.3 Cloud Gateway documentation says the renamed feature is not supported from that release onward, except for active users with a valid license. - A tenant must verify its own service status, forwarding, enforcement configuration, and message evidence before relying on the protection. ## How Cisco Advanced Phishing Protection works Cisco's [AsyncOS 16.0 integration guide](https://www.cisco.com/c/en/us/td/docs/security/esa/esa16-0/user_guide/b_ESA_Admin_Guide_16-0/m_advanced_phishing_protection.pdf) describes Cisco Advanced Phishing Protection as providing BEC and phishing-detection capabilities. It says the cloud service uses the email gateway as a sensor engine, receiving a copy of inbound message metadata, including headers, for analysis. That makes this a specific layer in an email-security design, not the same task as a general [secure email gateway explanation](/learning/how-secure-email-gateways-protect-organization) or a definition of [phishing](/learning/what-is-phishing). Cisco's documentation describes an integration path that begins with service access and a registered sensor, then makes metadata available for analysis. It does not make the product name alone evidence that a tenant is protected. Cisco also documents policy-dependent enforcement. Its integration guide says that preconfigured cloud-service policies, when configured with an Enforcement sensor, can block or redirect a message for investigation. Treat that as documentation of a configured path, not as proof of how a specific message was handled in a particular tenant. ## When the answer changes Product naming and support status matter here. Cisco's [AsyncOS 14.3 Cloud Gateway documentation](https://docs.ces.cisco.com/docs/asyncos-143) calls the feature Cisco Secure Email Phishing Defense, formerly Cisco Advanced Phishing Protection. It says the feature is no longer supported from Secure Email Cloud Gateway 14.3 onward, while noting that the statement does not apply to existing users with a valid license who are actively using it. So do not infer coverage from an old design diagram, a feature list, or the presence of a Cisco gateway. Verify the exact release and service status with Cisco for the deployment in question. Sender-domain controls are a separate layer: [DMARC](/learning/what-is-dmarc) helps receivers evaluate mail that claims to use a domain, but it does not prove that this Cisco service is enabled, licensed, or enforcing a tenant policy. ## A tenant-evidence map for the Cisco service Cisco documents a flow from gateway metadata to cloud analysis and then to configured enforcement. The final step below is an operational inference: service architecture cannot by itself establish what happened to one message. ![Evidence map separating Cisco gateway metadata, cloud analysis, configured enforcement, and tenant-specific message evidence.](/images/editorial/cisco-advanced-phishing-protection/cisco-advanced-phishing-protection-evidence-map.svg "1600x900") *Source: Original Palisade evidence map based on Cisco's [AsyncOS 16.0 integration guide](https://www.cisco.com/c/en/us/td/docs/security/esa/esa16-0/user_guide/b_ESA_Admin_Guide_16-0/m_advanced_phishing_protection.pdf). It organizes documented stages and does not depict a Cisco interface or prove a message outcome. [Open the full-size evidence map](/images/editorial/cisco-advanced-phishing-protection/cisco-advanced-phishing-protection-evidence-map.svg).* Use this short record during an authorized tenant review: ```text Release and license: confirmed for this deployment Service and sensor: active, registered, and connected Forwarding and policy: reviewed for the intended recipient scope Message evidence: permitted tracking, investigation, or controlled-test record reviewed Conclusion: state only what the evidence supports ``` ## What to verify before relying on the protection ### 1. Confirm the release, license, and active service Start with the gateway release and the service's current entitlement. Cisco's 16.0 guide lists a license and account activation among its prerequisites. The 14.3 Cloud Gateway support statement adds an important qualification for that release line. A product label in an inventory is not enough to establish current support. ### 2. Confirm the gateway is an active sensor Cisco's guide describes registering the email gateway as a sensor and enabling the service on that gateway. In a tenant review, establish that the intended gateway and the relevant mail path are actually connected. Do not infer sensor coverage for every route, cluster, or recipient merely because one gateway was once registered. ### 3. Confirm metadata forwarding and the enforcement policy The integration guide describes forwarding inbound message metadata and says configured policies can block or redirect messages when an Enforcement sensor is used. Review the scope and behavior that are actually configured for the mail flow under investigation. This is the point where a design can differ materially from a tenant's active controls. ### 4. Review permitted message evidence Cisco documents monitoring forwarded metadata and reporting successful or unsuccessful forwarding. Use authorized tracking, investigation records, or a controlled test appropriate to the organization. Do not declare a message safe, malicious, blocked, or remediated without evidence for that message and recipient path. ## Compare the documented gap before adding or changing a layer If you need to decide whether this Cisco layer fits your environment, compare its deployment and operating evidence with the native and dedicated options you are actually considering. [Compare anti-phishing software and deployment models](/learning/anti-phishing-software) A comparison framework cannot inspect a Cisco tenant or prove how a specific message was handled. ## Sources and further reading - [Cisco AsyncOS 16.0: Integrating the Email Gateway with Cisco Advanced Phishing Protection](https://www.cisco.com/c/en/us/td/docs/security/esa/esa16-0/user_guide/b_ESA_Admin_Guide_16-0/m_advanced_phishing_protection.pdf) - [Cisco Secure Email Cloud Gateway: AsyncOS 14.3](https://docs.ces.cisco.com/docs/asyncos-143) ## Frequently asked questions ### Is Cisco Advanced Phishing Protection the same as a secure email gateway? No. Cisco documents it as a cloud service that can use an email gateway as a sensor for message metadata. A secure email gateway is a broader mail-flow layer, and a gateway's presence does not by itself prove that the Cisco service is licensed, connected, configured, or active for a given recipient path. ### Does Cisco Advanced Phishing Protection block every phishing message? No. Cisco documents policy-dependent blocking or redirection when an Enforcement sensor is configured. That does not establish coverage for every tenant, recipient, route, or message. Confirm the active service, sensor, policy scope, and permitted message evidence before making a message-specific conclusion. ### Is Cisco Advanced Phishing Protection supported on AsyncOS 14.3 Cloud Gateway? Only with an important qualification. Cisco says the renamed Cisco Secure Email Phishing Defense feature is no longer supported from Secure Email Cloud Gateway 14.3 onward, but says that statement does not apply to existing users with a valid license who are actively using the feature. Verify the deployment with Cisco. ### Does DMARC verify Cisco Advanced Phishing Protection? No. DMARC provides sender-domain authentication and receiver policy information. It does not expose a Cisco tenant's license, sensor registration, metadata forwarding, enforcement policy, recipient scope, or the handling of an individual inbound message. ### What evidence should an administrator collect first? Collect the exact gateway release, license and service status, sensor registration and connection evidence, metadata-forwarding and enforcement-policy scope, and a permitted tracking or controlled-test record. Keep the final conclusion limited to what those tenant-specific records actually show.