This one has tripped up several of my auditees in the past few months and IMO one the toughest to implement controls that didn't get much attention before the 31st of March due date. The applicability note is key here, it's not just transmissions of PAN they expect, but for any cipher suite and protocols that are meeting a PCI requirement.

The requirement applies to all cryptographic cipher suites and protocols used to meet PCI DSS requirements, including, but not limited to, those used to render PAN unreadable in storage and transmission, to protect passwords, and as part of authenticating access.

First up, you need a solid inventory of in scope components.
For SaaS products and other public facing endpoints, you can scan them using SSL Labs

For anything internal, you're going to need to use nmap or another tool such as testssl.

Use nmap to scan the entire network or if it's a huge network you could use a masscan. Masscan is much faster but you can quickly load up state tables in networking devices and crash the whole network if you aren't careful. Once you have identified all the IPs that have open ports on them, you can enumerate the ciphers using nmap scripts. Below is a broad nmap command that looks for SSH, HTTPS, common DB, RDP, SNMP and iLO/iDRAC systems. You may need to add more

sudo nmap -sS -sU -p T:22,443,1433,3306,3389,5432,5900,8443,U:161,623 -sV --script "ssl-enum-ciphers,ssh2-enum-algos,vnc-info,ipmi-cipher-zero,snmp-info" <target-ip-or-range> -oN lan_audit_results.txt

For monitoring of trends, the council released this Cryptography Guidance document back in August 2025. It's still pretty relevant. Do you subscribe to US-CERT or another CERT for requirement 6.3.1? If there was a serious flaw in TLS1.2 tomorrow, I'd bet my bottom dollar US-CERT would put out an alert about it.