A bank's security team must learn which client applications on user endpoints are opening TLS sessions through its FTD devices, but a compliance rule forbids terminating TLS with a man-in-the-middle decryption policy. The FMC manages Snort 3 devices. Which control gives the team client-application visibility into those encrypted sessions?

The Encrypted Visibility Engine (EVE) is the appropriate control because it uses TLS Client Hello characteristics, including fingerprints, to infer the client application associated with encrypted sessions. It provides that application-level visibility on supported Snort 3 devices without terminating TLS or inspecting decrypted payloads, so it meets both the visibility need and the compliance constraint. TLS Server Identity Discovery instead uses certificate information to characterize the server side of a connection; knowing which server a session reaches does not identify the client application that opened it. SNI-based URL categorization can classify a requested hostname or web destination when that metadata is available, but a destination label is not an application identity: different applications can contact the same host, and an application can contact many hosts. Exporting flow metadata is useful for inventory and traffic analysis, but endpoint, protocol, and port fields describe connections rather than reliably distinguishing the client applications that initiated them. Exam caveat: TLS fingerprinting is an inference from observable handshake features, not a guarantee of application identity; shared libraries, fingerprint changes, and encrypted Client Hello can limit identification. Practical check: verify EVE support and configuration on the target FTD/Snort 3 release, then review FMC events for known test applications and confirm that visibility is achieved without enabling TLS decryption.