The Council's threshold for encryption and hashing that counts under PCI DSS: an algorithm the industry has tested and accepts, keys that give at least 112 bits of effective strength (128 recommended for new implementations), and proper key management behind them. Effective strength is the measure, not the nominal key length, so a long key on a weak algorithm can still fall short. The standard names no algorithms; the Council points to industry references such as NIST SP 800-57 Part 1, which put AES with 128-bit keys or longer, RSA with 2048-bit keys or longer and TLS 1.2 or higher on the right side of the line and SSL, early TLS, DES and SHA-1 signatures on the wrong side. An approved algorithm used with weak keys, a poor mode of operation or careless key storage is not strong cryptography.
Applies to. Strong cryptography is the standard's yardstick wherever it requires data to be encrypted or rendered unreadable. In Requirement 3 it governs stored PAN under 3.5.1, SAD stored before authorisation under 3.3.2, and SAD retained by issuers under 3.3.3. Elsewhere it applies to PAN in transit over open, public networks under 4.2.1, wireless networks under 4.2.1.2, end-user messaging under 4.2.2, non-console administrative access under 2.2.7, and authentication factors in storage and transit under 8.3.2.
Example. A merchant's assessor asks how stored PAN is protected and is told that it is encrypted. That answer is not enough: the merchant has to show the algorithm and key length, the key-management procedures under 3.6 and 3.7, and that the encryption is applied to the data itself rather than only to the disk. A second merchant sending PAN to its acquirer has to show the protocol configuration rejects fallback to insecure versions, algorithms or key sizes, as 4.2.1 requires.
Limits. Strong cryptography is a threshold, not a named list: the standard sets a minimum effective key strength and points to industry references, and it does not name algorithms in the requirements, so the entity has to show that its chosen algorithm and key length meet the bar. Effective strength is not the same as nominal key length; an algorithm with a long key can still fall short. Strong cryptography is also conditional on key management: the same algorithm with keys stored beside the data, or never changed, does not qualify. Deprecated protocols and algorithms drop out over time, which is why 12.3.3 requires a review of cipher suites and protocols at least once every 12 months.