A logistics firm runs an in-house scheduling app on TCP 9443, and an unrelated service also listens on that port. The team wants the FMC network map to record the app from live traffic by matching a marker at the start of each session while servers stay unmodified. Which configuration should the engineer create to identify this application in network discovery?

Network discovery builds the asset inventory from traffic the sensor already sees, and application identity comes from application detectors. Because a second service shares TCP 9443, a custom application detector is the right tool: it pairs the transport port with a payload pattern and a byte offset, so only sessions carrying your marker get labeled, and the discover-applications action in the rule is what writes that label into the network map. A detector built from the port alone labels both services, so the map still cannot separate your scheduling app from its neighbor. An intrusion policy rule takes a different road entirely: it raises a security event when traffic matches a signature, which is useful for detection but never contributes an application identity to discovery data, so the inventory goal stays unmet. An application filter works from predefined application identities inside an access control policy, and its job is to permit or block traffic rather than to learn an unknown in-house protocol, so it also misses the mapping goal. Exam caveat: detector patterns may need tuning when payloads vary, and Cisco-provided detectors can change with VDB updates. Practical check: open the host in the network map after deployment and confirm the application name appears, then send a session without the marker to prove the pattern is doing the work.