For Configuration Scan Outcome Analysis

This guide provides a detailed overview of the Configuration Quantum Readiness Report, explaining each section and offering guidance on how to interpret the results. It focuses on identifying cryptographic protocols, libraries, ciphers, and bound certificates that may affect your organization's readiness to transition to post-quantum cryptography.

Scope of Discovery

The configuration scan operates using an agent-based model:
  • Agent Deployment: A lightweight agent is installed on servers or application hosts
  • Local Discovery: The agent inspects system configuration files, SSL/TLS settings, crypto libraries, and certificate bindings locally
  • Full Visibility: This ensures discovery of all protocols, libraries, and ciphers in use as well as certificates actively bound to services
  • Accuracy: Because discovery is performed locally, the scan is not limited by network visibility and cannot be bypassed by load balancers or intermediate proxies.

Protocols

What it shows:

All SSL/TLS protocols used by servers running in the endpoint.

Why visibility into all configured protocols is required for PQC migration?

Even if system is configured to prefer TLS 1.2 or TLS 1.3, legacy protocols like SSLv2, SSLv3, TLS 1.0, and TLS 1.1 remain exploitable if they are still enabled because

  • Downgrade attacks
    • Attackers can trick a client and server into falling back to a weaker protocol that both still support.
  • Negotiation flexibility
    • Some older clients may still attempt connections using weak protocols
    • If accepted, these connections are insecure, exposing data and credentials.
  • Known cryptographic flaws
    • SSLv2/SSLv3/TLS 1.0/1.1 use broken primitives (e.g., RC4, MD5, weak MACs) that can be exploited regardless of preference order.
  • Quantum readiness impact
    • Legacy protocols cannot support modern cipher suites or PQC-hybrid extensions, making them blockers for future migration.
Action:
  • Disable SSLv2, SSLv3, TLS 1.0, and TLS 1.1
  • Require TLS 1.2 minimum; prefer TLS 1.3
  • Validate vendor support for PQC enabled TLS extensions
  • Ensure cipher suites under each protocol are modern (Eg:AES-GCM/ChaCha20) with forward secrecy.

Libraries

What it shows:

All cryptographic libraries and frameworks used by the supported servers (e.g., OpenSSL, BouncyCastle, WolfSSL, JCE), including their versions.

Why it matters:

Unsupported or outdated libraries introduce vulnerabilities and block Post Quantum Cryptographic adoption. Only modern libraries will integrate NIST-standard PQC algorithms.

Action:
  • Upgrade to the latest supported versions
  • Standardize libraries across environments
  • Select libraries with active PQC support or published migration roadmaps.

Ciphers

What it shows:

All cipher suites defined in the SSL/TLS configuration that are in use.

Why visibility into all configured options is required for PQC migration?
Even if a system prefers strong modern algorithms, the full list of configured options still matters, because
  • Downgrade attacks
    • If weak or legacy ciphers/protocols (e.g., RSA key exchange, 3DES, TLS 1.0) remain enabled, an attacker can force a fallback to them bypassing the “preferred” PQC-ready choice.
  • Quantum readiness depends on availability, not preference
    • PQC migration planning requires knowing which algorithms and key exchanges are actually allowed, not just which ones are typically used in negotiation
    • If classical-only suites are still configured, the environment is not quantum-ready.
  • Consistency across environments
    • Inconsistent configurations between servers, services, and applications can lead to some endpoints being PQC-ready while others remain vulnerable
    • Discovery of all configured options ensures alignment.
  • Audit and compliance requirements
    • Regulators and auditors expect proof that legacy/quantum-vulnerable algorithms are fully disabled, not just unused.
Action:
  • Remove weak/deprecated ciphers
  • Enforce forward-secrecy suites (ECDHE + AES-GCM/ChaCha20)
  • Prepare migration strategy for PQC-hybrid suites once standardized.

How Cipher Suites are grouped for PQC readiness evaluation

When the system scans a server (for example, an Apache web server), it identifies all the cipher suites the server supports under protocols like TLS 1.2 or TLS 1.3.

These cipher suites determine how secure communication is established, including how keys are exchanged, how identities are verified, and how data is encrypted.

Example: Cipher Suites Retrieved from an Apache Server

When a PQC discovery scan runs against an Apache endpoint, the system might retrieve a list like this for each service binding:

Cipher Suite Key Exchange Authentication
TLS_DH_RSA_WITH_AES_256_GCM_SHA384 DH RSA
TLS_DHE_RSA_WITH_AES_128_GCM_SHA256 DHE RSA
TLS_ECDH_RSA_WITH_AES_256_GCM_SHA384 ECDH RSA
TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 ECDHE RSA
TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384 ECDHE ECDSA
TLS_AES_256_GCM_SHA384 ECDHE ML-DSA
TLS_CHACHA20_POLY1305_SHA256 ML-KEM RSA
TLS_AES_256_GCM_SHA384 ML-KEM ML-DSA
TLS_DH_anon_WITH_AES_128_CBC_SHA DH None
This list shows a mix of classical and PQC configurations, which the platform then analyzes and groups based on their cryptographic properties.

Step 1: Discover Cipher Suites

Every discovered cipher suite contains three building blocks
  1. Key Exchange: how systems agree on a shared secret key.
  2. Authentication: how the server (or client) proves its identity.
  3. Encryption: how data is protected after the handshake.
  4. Hashing: how data integrity is ensured.
The scanner extracts the first two because they determine quantum vulnerability.

Examples from the Apache scan:

  • TLS_DHE_RSA_WITH_AES_128_GCM_SHA256 → DHE (key exchange), RSA (auth)
  • TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384 → ECDHE (key exchange), ECDSA (auth)
  • TLS_AES_256_GCM_SHA384 → ML-KEM (key exchange), ML-DSA (auth).

Step 2: Classify Algorithms by Type

Each algorithm is classified as Classical, Hybrid, or PQC based on its cryptographic foundation.
Category Example Algorithms
Classical DH, DHE, ECDH, ECDHE, RSA, ECDSA
Hybrid ECDHE + ML-DSA, X25519MLKEM768
PQC ML-KEM, SLH-DSA, ML-DSA(signatures)

Step 3: Apply Grouping Logic

Grouping removes redundancy and focuses on unique cryptographic behavior
Condition Grouping Behavior in inventory Details
Same key exchange + same authentication Grouped together Both handshake stages are identical & same cryptographic behavior
Same key exchange, but different authentication Separate groups Authentication uses different signing algorithms
Different key exchanges, even with same authentication Separate groups Key generation and mathematical base differ
PQC or hybrid key exchanges (Kyber, Kyber+RSA) Separate groups Represents distinct cryptographic families
Anonymous (no authentication) Separate group Insecure

Step 4: Grouped Results in the Inventory

After grouping, the Apache example appears as:
Protocol Key Exchange Group Authentication Cipher Suites Included in Group
TLS 1.3 DH RSA TLS_DH_RSA_WITH_AES_256_GCM_SHA384
TLS 1.3 DHE RSA TLS_DHE_RSA_WITH_AES_128_GCM_SHA256
TLS 1.3 ECDH RSA TLS_ECDH_RSA_WITH_AES_256_GCM_SHA384
TLS 1.3 ECDHE RSA TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384
TLS 1.3 ECDHE ECDSA TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384
TLS 1.3 ECDHE ML-DSA TLS_AES_256_GCM_SHA384
TLS 1.3 ML-KEM RSA TLS_CHACHA20_POLY1305_SHA256
TLS 1.3 ML-KEM ML-DSA TLS_AES_256_GCM_SHA384
TLS 1.3 DH (Anonymous) None TLS_DH_anon_WITH_AES_128_CBC_SHA

Step 5: Why Grouping Happens

Grouping cipher suites isn’t just about simplifying the report, it's about ensuring accuracy, clarity, and meaningful analysis of your cryptographic posture.
Each cipher suite defines a unique combination of
  • Key Exchange: how the encryption key is negotiated
  • Authentication: how the endpoint’s identity is verified.
Grouping ensures that suites with identical handshake behavior and equal PQC risk are treated as a single entry, rather than being repeated multiple times.

To Represent Unique Cryptographic Behavior

Every key exchange and authentication pairing represents a distinct handshake pattern.
By grouping cipher suites with the same key exchange and same authentication, the system ensures that:
  • Each group reflects a unique mathematical process, and
  • No unrelated ciphers are mixed together.
For example:
  • All ECDHE_RSA ciphers perform the exact same key negotiation and identity check → grouped together but DHE_RSA or ECDHE_ECDSA differ in key exchange or authentication → shown separately.
This makes each row in the PQC inventory represent one precise cryptographic combination.

To Maintain Quantum Risk Accuracy

Even small variations in cipher structure (like DH vs ECDHE or RSA vs ECDSA) affect how they’ll perform against quantum attacks.

Grouping only by identical key exchange and authentication ensures the PQC readiness score is accurate

  • DH/DHE and ECDHE/ECDH rely on different mathematical bases (integer-field vs elliptic-curve).
  • RSA and ECDSA use different signature schemes that will migrate to different PQC replacements.
Grouping based on exact match ensures that each quantum risk level is correctly calculated.

To Provide a Clearer, More Actionable Inventory

In a real environment, endpoints may support dozens of cipher suites, many of which differ only slightly.
  • Without grouping, your PQC readiness report would list:
    • 20+ nearly identical lines with minimal variation.
  • By grouping logically identical suites:
    • You get one consolidated row per unique combination
      • DHE (RSA)
      • ECDHE (ECDSA)
      • ML-KEM (ML-DSA)
      • ML-KEM (RSA)
    • Making it easy to identify which types of handshakes still rely on classical cryptography.
This makes PQC readiness results shorter, cleaner, and directly actionable.

Bound Certificates

What it shows:
  • Certificates bound to services/endpoints: These are the active digital certificates actually in use by web servers, load balancers, APIs, mail servers, or applications
  • Details captured:
    • Algorithm type (RSA, ECC, ECDSA, EdDSA)
    • Key length (RSA-2048, RSA-3072, ECC-256, etc.)
    • Issuer (internal CA, public CA, self-signed)
    • Usage (server auth, client auth, code signing, etc.)
  • Not included: Certificates that simply exist in a trust store (root CAs, unused intermediates) but are not actively bound to a service.
Why it matters:
  • Trust & authentication
    • Bound certificates are what clients (browsers, apps, APIs) actually see and rely on to establish trust.
    • If these are weak, expired, or misconfigured, secure communication breaks down.
  • Exposure to quantum threats
    • Most bound certificates today use RSA or ECC. Both will be breakable by a sufficiently powerful quantum computer.
    • Attackers could use harvested traffic and decrypt it later (“store now, decrypt later” risk).
  • Operational risk
    • Weak key lengths (RSA < 2048, ECC < 256) can already be broken or are considered insufficient.
    • Long-lived certificates increase risk exposure and make migration harder.
  • PQC migration dependency
    • For an organization to adopt PQC or hybrid certificates, visibility into which certificates are actually bound is essential.
    • This ensures you can prioritize the right endpoints for testing, replacement, and staged migration.
Action:
  • Inventory all bound certificates and document their algorithms and key lengths
  • Decommission weak certificates (RSA < 2048, ECC < 256)
  • Implement short-lived certificates (≤ 1 year) with automated renewal
  • Begin pilots with hybrid/PQC certificates where supported by your CA/vendor
  • Align certificate management policies with future NIST PQC standards.

PQC Score Calculator

The PQC Score Calculator for Configuration Scan measures the quantum resilience of system and application cryptographic configurations by analyzing the protocol versions, cipher suites, key exchange mechanisms, and algorithms defined within them.It helps identify whether configurations are quantum-safe, hybrid, or vulnerable to future quantum attacks by assessing the algorithm types, key strengths, and overall cryptographic posture used across the environment

Using standardized criteria based on NIST PQC guidelines and quantum threat models (such as Shor’s and Grover’s algorithms), the calculator assigns a numerical score that reflects the level of readiness for post-quantum security

Type Score
Quantum Resistant crypto categories identified 1
Quantum Vulnerable crypto categories identified 0

PQC Score = ∑(Quantum-Resistant Crypto Categories identified) / (Total Crypto Categories) X *10

Explanation

  • ∑(Count of Quantum Resistant crypto categories identified) → The sum of all crypto assets that are identified as Quantum Resistant.
  • Total Crypto categories → The total number of crypto assets identified across the configurations.
  • The result is multiplied by 10 to convert it into a 1–10 scale.

Eg: Assume you have 100 Crypto assets identified.

Quantum-Vulnerable & Quantum-Resistant values derived from Quantum Readiness column value.

Crypto categories Total Total Quantum-Vulnerable Total Quantum-Resistant
Protocols 50 45 5
Certificates 10 5 5
Cryptographic Library 40 30 10
  • Total crypto categories (Protocols+Certificates +Cryptographic library)→ 100
  • Total Quantum vulnerable crypto categories identified (Protocols+Certificates +Cryptographic library)→ 80
  • Total Quantum-Resistant crypto categories identified(Protocols+Certificates +Cryptographic library) → 20

Example calculation

PQC Score = (20/100)*10 = 2

Threat Level Interpretation

Severity Calculation

Scenario: Apache Application Cipher Discovery
During the PQC readiness scan, the Apache web server exposes the following TLS cipher suites in its configuration.
Cipher Suite Key Exchange (KX) Authentication (AUTH) Encryption (ENC) Hash (HASH)
TLS_AES_256_GCM_SHA384 ML-KEM RSA-2048 AES-256 SHA-384
TLS_AES_128_GCM_SHA256 ML-KEM RSA-2048 AES-128 SHA-256
TLS_ECDH_RSA_AES256_SHA384 ECDH X25519 RSA-2048 AES-256 SHA-384
TLS_CHACHA20_POLY1305_SHA256 ML-KEM ECDSA CHACHA20 SHA-256
TLS_AES_256_GCM_SHA384 ML-KEM ML-DSA AES-256 SHA-384
These represent the mix of classical and post-quantum (PQC) algorithms configured for HTTPS traffic.

Step 1: Grouping Logic

Cipher suites are grouped by their Key Exchange (KX) and Authentication (AUTH) combinations because these define their quantum risk behavior.
Encryption (ENC) and Hashing (HASH) differences have minimal PQC impact and are averaged per group.
Group Cipher Suites Included KX AUTH
G1 TLS_AES_256_GCM_SHA384

TLS_AES_128_GCM_SHA256

 ML-KEM RSA-2048
G2 TLS_ECDH_RSA_AES256_SHA384 ECDH X25519 RSA-2048
G3 TLS_CHACHA20_POLY1305_SHA256 ML-KEM ECDSA
G4 TLS_AES_256_GCM_SHA384 ML-KEM ML-DSA

Step 2: Weighted Scoring Formula

Each function contributes differently to the total score based on impact weight
Function Weight Rationale
KX 0.4 Most critical (Harvest-Now, Decrypt-Later risk)
AUTH 0.3 Identity forgery risk
ENC 0.2 Symmetric risk minimal but counted
HASH 0.1 Lowest impact
PQC Weighted Score = (0.40×KX) + (0.30×AUTH) + (0.20×ENC) + (0.10×HASH)

Step 3: Calculate Scores per Cipher Group

Group KX AUTH ENC HASH Weighted Score Calculation Base Score Base Severity
G1: (ML-KEM, RSA-2048) 100 0 100 100 (0.4×100) + (0.3×0) + (0.2×100) + (0.1×100) = 70 70 Moderate
G2: (X25519, RSA-2048) 0 0 100 100 (0.4×0) + (0.3×0) + (0.2×100) + (0.1×100) = 30 30 Critical
G3: (ML-KEM, ECDSA) 100 0 100 100 (0.4×100) + (0.3×0) + (0.2×100) + (0.1×100) = 70 70 Moderate
G4: (ML-KEM, ML-DSA) 100 100 100 100 (0.4×100) + (0.3×100) + (0.2×100) + (0.1×100) = 100 100 Low

After Applying Gates:

Group Base Severity Gate Triggered Final Severity Reason
G1 Moderate AUTH Gate High AUTH = RSA-2048 (classical)
G2 Critical KX Gate Critical KX = X25519 (classical)
G3 Moderate AUTH Gate High AUTH = ECDSA (classical)
G4 Low None Low Fully PQC (ML-KEM + ML-DSA)

Step 4: Final Results Summary

Group Cipher Families Weighted Score Final Severity Migration Priority
G1 ML-KEM + RSA-2048 70 High Replace RSA with PQC/Hybrid signature (e.g., ML-DSA)
G2 X25519 + RSA-2048 30 Critical Upgrade both KX and AUTH to PQC
G3 ML-KEM + ECDSA 70 High Replace ECDSA with PQC signature
G4 ML-KEM + ML-DSA 100 Low Fully PQC-ready
Range Severity Meaning
85–100 Low Fully PQC-ready
70–84 Moderate Partial PQC adoption
40–69 High PQC adoption incomplete
<40 Critical Classical only — immediate migration required
Note: For Cipher suite gating criteria as mentioned above will be used and severity will not be determined on the actual key exchange and auth algorithms listed below apart from the deprecated algorithms.

If any deprecated algorithm is used in Key exchange or Authentication or Hashing or Encryption ,the protocol severity will be directly marked critical

These are for references to NIST and Shor’s analysis on breaking an algorithm:

Key Exchange
Algorithm NIST / FIPS Status Quantum Status PQC Severity
RSA-512 Approved (FIPS 186-2, Deprecated) Quantum Vulnerable Critical
RSA-768 Approved (FIPS 186-2, Deprecated) Quantum Vulnerable Critical
RSA-1024 Approved (FIPS 186-2, Deprecated) Quantum Vulnerable Critical
RSA-1536 Approved (FIPS 186-2, Deprecated) Quantum Vulnerable Critical
RSA-2048 Approved (FIPS 186-4) Quantum Vulnerable High
RSA-3072 Approved (FIPS 186-4) Quantum Vulnerable High
RSA-4096 Approved (FIPS 186-4) Quantum Vulnerable High
RSA-6144 Approved (FIPS 186-4) Quantum Vulnerable High
RSA-7680 Not Approved Quantum Vulnerable High
RSA-8192 Approved (FIPS 186-4) Quantum Vulnerable High
RSA-12288 Not Approved Quantum Vulnerable High
RSA-15360 Not Approved Quantum Vulnerable High
DH-1024 Approved (SP 800-56A, Deprecated <2048-bit) Quantum Vulnerable Critical
DH-2048 Approved (SP 800-56A) Quantum Vulnerable High
DH-3072 Approved (SP 800-56A) Quantum Vulnerable High
DH-4096 Approved (SP 800-56A) Quantum Vulnerable High
DHE-2048 Approved (SP 800-56A) Quantum Vulnerable High
DHE-3072 Approved (SP 800-56A) Quantum Vulnerable High
DHE-4096 Approved (SP 800-56A) Quantum Vulnerable High
ECDH-P192 Approved (FIPS 186-2, Deprecated) Quantum Vulnerable Critical
ECDH-P224 Approved (FIPS 186-4, Deprecated) Quantum Vulnerable Critical
ECDH-P256 Approved (FIPS 186-4) Quantum Vulnerable High
ECDH-P384 Approved (FIPS 186-4) Quantum Vulnerable High
ECDH-P521 Approved (FIPS 186-4) Quantum Vulnerable High
ECDH-brainpoolP256r1 Not Approved (RFC 5639, widely used in EU) Quantum Vulnerable High
ECDH-brainpoolP384r1 Not Approved (RFC 5639) Quantum Vulnerable High
ECDH-brainpoolP512r1 Not Approved (RFC 5639) Quantum Vulnerable High
ECDH-secp256k1 Not Approved (Bitcoin/Blockchain curve) Quantum Vulnerable High
ECDHE-P192 Approved (FIPS 186-2, Deprecated) Quantum Vulnerable Critical
ECDHE-P224 Approved (FIPS 186-4, Deprecated) Quantum Vulnerable Critical
ECDHE-P256 Approved (FIPS 186-4) Quantum Vulnerable High
ECDHE-P384 Approved (FIPS 186-4) Quantum Vulnerable High
ECDHE-P521 Approved (FIPS 186-4) Quantum Vulnerable High
ECDHE-brainpoolP256r1 Not Approved (RFC 5639) Quantum Vulnerable High
ECDHE-brainpoolP384r1 Not Approved (RFC 5639) Quantum Vulnerable High
ECDHE-brainpoolP512r1 Not Approved (RFC 5639) Quantum Vulnerable High
ECDHE-secp256k1 Not Approved Quantum Vulnerable High
ML-KEM-512 NIST PQC Finalist (FIPS 203 draft) Quantum Resistant Low (Quantum Safe)
ML-KEM-768 NIST PQC Finalist (FIPS 203 draft) Quantum Resistant Low (Quantum Safe)
ML-KEM-1024 NIST PQC Finalist (FIPS 203 draft) Quantum Resistant Low (Quantum Safe)
SecP256r1MLKEM768 In Draft (NIST migration guidance) Hybrid Medium
X25519MLKEM768 In Draft (NIST migration guidance) Hybrid Hybrid
SecP384r1MLKEM1024 In Draft (NIST migration guidance) Hybrid Hybrid

Authentication

  • Certificates rated by risk level
Cert Type Description Certificate Validity Window NIST PQC Timeline Severity
Classical: RSA ≤ 2048 bits ~112-bit classical strength After 2030 Insecure beyond 2030 Critical
Classical: RSA ≤ 2048 bits ~112-bit classical strength On/before 2030 Allowed within window High
Classical: RSA 2048–3071 bits ~112–128-bit classical strength After 2035 Insecure beyond 2035 Critical
Classical: RSA 2048–3071 bits ~112–128-bit classical strength On/before 2035 Allowed within window High
Classical: RSA ≥ 3072 bits ≥128-bit classical strength Any Classical secure High
Classical: DSA ≤ 1024 bits Weak / legacy Any Already insecure Critical
Classical: DSA ≤2048 bits Moderate classical strength Any Classical secure High
Classical: DSA ≥ 3072 bits Strong classical strength Any Classical secure High
Classical: ECC < P‑256 Weak curve After 2030 Insecure beyond 2030 Critical
Classical: ECC < P‑256 Weak curve On/before 2030 Allowed within window High
Classical: ECC ≥ P‑256 Modern curve Any Classical secure High
Classical: ECC P‑384 / P‑521 Strong curve Any Classical secure High
Classical: Ed25519 / Ed448 Modern curve Any Classical secure High
Hybrid: RSA + PQC Classical + PQC Any Recommended now → post-2035 Low (Quantum Safe)
Hybrid: ECC + PQC Classical + PQC Any Recommended now → post-2035 Low (Quantum Safe)
Pure PQC

ML-KEM

ML-DSA

SLH-DSA

 Any Recommended now → post-2035 Low (Quantum Safe)
Encryption
Algorithm NIST Status Severity PQC Readiness
AES-128 Approved (FIPS 197) High Quantum Vulnerable
AES-192 Approved (FIPS 197) High Quantum Vulnerable
AES-256 Approved (FIPS 197) Low (Quantum Safe) Quantum Resistant
AES-128-ECB Approved (FIPS 197) High Quantum Vulnerable
AES-192-ECB Approved (FIPS 197) High Quantum Vulnerable
AES-256-ECB Approved (FIPS 197) High Quantum Vulnerable
AES-128-CBC Approved (FIPS 197 / SP 800-38A) High Quantum Vulnerable
AES-192-CBC Approved (FIPS 197 / SP 800-38A) High Quantum Vulnerable
AES-256-CBC Approved (FIPS 197 / SP 800-38A) Low (Quantum Safe) Quantum Resistant
AES-128-CTR Approved (FIPS 197 / SP 800-38A) High Quantum Vulnerable
AES-192-CTR Approved (FIPS 197 / SP 800-38A) High Quantum Vulnerable
AES-256-CTR Approved (FIPS 197 / SP 800-38A) Low (Quantum Safe) Quantum Resistant
AES-128-GCM Approved (FIPS 197 / SP 800-38D) High Quantum Vulnerable
AES-192-GCM Approved (FIPS 197 / SP 800-38D) High Quantum Vulnerable
AES-256-GCM Approved (FIPS 197 / SP 800-38D) Low (Quantum Safe) Quantum Resistant
Camellia-128-CBC Approved (ISO/IEC 18033-3 / JIS X 6319-3) High Quantum Vulnerable
Camellia-192-GCM Approved (ISO/IEC 18033-3 / JIS X 6319-3) High Quantum Vulnerable
Camellia-256-GCM Approved (ISO/IEC 18033-3 / JIS X 6319-3) Low (Quantum Safe) Quantum Resistant
CAMELLIA-128 Approved / Recognized (SP 800-57) High Quantum Vulnerable
CAMELLIA-192 Approved / Recognized (SP 800-57) High Quantum Vulnerable
CAMELLIA-256 Approved / Recognized (SP 800-57) Low (Quantum Safe) Quantum Resistant
Camellia-192-CBC Approved (ISO/IEC 18033-3 / JIS X 6319-3) High Quantum Vulnerable
Camellia-256-CBC Approved (ISO/IEC 18033-3 / JIS X 6319-3) Low (Quantum Safe) Quantum Resistant
Camellia-128-GCM Approved (ISO/IEC 18033-3 / JIS X 6319-3) High Quantum Vulnerable
CAMELLIA-128-CTR Approved / Recognized (SP 800-57) High Quantum Vulnerable
CAMELLIA-192-CTR Approved / Recognized (SP 800-57) High Quantum Vulnerable
CAMELLIA-256-CTR Approved / Recognized (SP 800-57) Low (Quantum Safe) Quantum Resistant
CAMELLIA-128-CCM Approved / Recognized (SP 800-38C, ISO/IEC 18033-3) High Quantum Vulnerable
CAMELLIA-192-CCM Approved / Recognized (SP 800-38C, ISO/IEC 18033-3) High Quantum Vulnerable
CAMELLIA-256-CCM Approved / Recognized (SP 800-38C, ISO/IEC 18033-3) Low (Quantum Safe) Quantum Resistant
AES-128-CCM Approved (FIPS 197 / SP 800-38C) High Quantum Vulnerable
AES-192-CCM Approved (FIPS 197 / SP 800-38C) High Quantum Vulnerable
AES-256-CCM Approved (FIPS 197 / SP 800-38C) Low (Quantum Safe) Quantum Resistant
AES-128-OCB Approved (FIPS 197 / RFC 7253) High Quantum Vulnerable
AES-192-OCB Approved (FIPS 197 / RFC 7253) High Quantum Vulnerable
AES-256-OCB Approved (FIPS 197 / RFC 7253) Low (Quantum Safe) Quantum Resistant
AES-128-XTS Approved (SP 800-38E) High Quantum Vulnerable
AES-256-XTS Approved (SP 800-38E) Low (Quantum Safe) Quantum Resistant
AES-128-CFB Approved (SP 800-38A) High Quantum Vulnerable
AES-192-CFB Approved (SP 800-38A) High Quantum Vulnerable
AES-256-CFB Approved (SP 800-38A) Low (Quantum Safe) Quantum Resistant
AES-128-CFB1 Approved (SP 800-38A) High Quantum Vulnerable
AES-192-CFB1 Approved (SP 800-38A) High Quantum Vulnerable
AES-256-CFB1 Approved (SP 800-38A) Low (Quantum Safe) Quantum Resistant
AES-128-CFB8 Approved (SP 800-38A) High Quantum Vulnerable
AES-192-CFB8 Approved (SP 800-38A) High Quantum Vulnerable
AES-256-CFB8 Approved (SP 800-38A) Low (Quantum Safe) Quantum Resistant
AES-128-OFB Approved (SP 800-38A) High Quantum Vulnerable
AES-192-OFB Approved (SP 800-38A) High Quantum Vulnerable
AES-256-OFB Approved (SP 800-38A) Low (Quantum Safe) Quantum Resistant
AES-128-SIV Approved (SP 800-38F) High Quantum Vulnerable
AES-192-SIV Approved (SP 800-38F) High Quantum Vulnerable
AES-256-SIV Approved (SP 800-38F) Low (Quantum Safe) Quantum Resistant
AES-128-WRAP Approved (SP 800-38F) High Quantum Vulnerable
AES-192-WRAP Approved (SP 800-38F) High Quantum Vulnerable
AES-256-WRAP Approved (SP 800-38F) Low (Quantum Safe) Quantum Resistant
AES-128-KW Approved (SP 800-38F) High Quantum Vulnerable
AES-192-KW Approved (SP 800-38F) High Quantum Vulnerable
AES-256-KW Approved (SP 800-38F) Low (Quantum Safe) Quantum Resistant
3DES-112 Approved (FIPS 46-3 / SP 800-67) High Quantum Vulnerable
3DES-168 Approved (FIPS 46-3 / SP 800-67) High Quantum Vulnerable
Blowfish-128 Not Approved / Legacy Critical Quantum Vulnerable
Blowfish-192 Not Approved / Legacy Critical Quantum Vulnerable
Blowfish-256 Not Approved / Legacy Critical Quantum Vulnerable
Twofish-128 Not Approved / Legacy High Quantum Vulnerable
Twofish-192 Not Approved / Legacy High Quantum Vulnerable
Twofish-256 Not Approved / Legacy High Quantum Vulnerable
Threefish-256 Not Approved / Legacy High Quantum Vulnerable
Threefish-512 Not Approved / Legacy Low (Quantum Safe) Quantum Resistant
THREEFISH-1024 Not Approved / Legacy Low (Quantum Safe) Quantum Resistant
Serpent -128 Not Approved / Legacy High Quantum Vulnerable
Serpent -192 Not Approved / Legacy High Quantum Vulnerable
Serpent -256 Not Approved / Legacy Low (Quantum Safe) Quantum Resistant
ChaCha20 Not FIPS-approved Low (Quantum Safe) Quantum Resistant
XChaCha20 Not FIPS-approved Low (Quantum Safe) Quantum Resistant
ChaCha20-Poly1305 Not FIPS-approved Low (Quantum Safe) Quantum Resistant
XChaCha20-Poly1305 Not FIPS-approved Low (Quantum Safe) Quantum Resistant
AES-128-POLY1305 Approved / FIPS 197, SP 800-38D High Quantum Vulnerable
AES-192-POLY1305 Approved / FIPS 197, SP 800-38D High Quantum Vulnerable
AES-256-POLY1305 Approved / FIPS 197, SP 800-38D Low (Quantum Safe) Quantum Resistant
DES-56 Deprecated (FIPS 46-3) Critical Quantum Vulnerable
RC2-40 Deprecated (SP 800-38 / Legacy) Critical Quantum Vulnerable
RC2-64 Deprecated (SP 800-38 / Legacy) Critical Quantum Vulnerable
RC2-128 Deprecated (SP 800-38 / Legacy) Critical Quantum Vulnerable
RC4-40 Deprecated / Weak Critical Quantum Vulnerable
RC4-128 Deprecated / Weak Critical Quantum Vulnerable
RC2-256 Deprecated / Weak Critical Quantum Vulnerable
RC4-40 Deprecated / Weak Critical Quantum Vulnerable
RC4-64 Deprecated / Weak Critical Quantum Vulnerable
RC4-128 Deprecated / Weak Critical Quantum Vulnerable
RC4-256 Deprecated / Weak Critical Quantum Vulnerable
RC5-32-128 Deprecated / Weak Critical Quantum Vulnerable
RC5-32-192 Deprecated / Weak Critical Quantum Vulnerable
RC5-32-256 Deprecated / Weak Critical Quantum Vulnerable
RC5-64-128 Deprecated / Weak Critical Quantum Vulnerable
RC5-64-192 Deprecated / Weak Critical Quantum Vulnerable
RC5-64-256 Deprecated / Weak Critical Quantum Vulnerable
RC5-128-128 Deprecated / Weak Critical Quantum Vulnerable
RC5-128-192 Deprecated / Weak Critical Quantum Vulnerable
RC5-128-256 Deprecated / Weak Critical Quantum Vulnerable
RC6-128 Not FIPS-approved High Quantum Vulnerable
RC6-192 Not FIPS-approved High Quantum Vulnerable
RC6-256 Not FIPS-approved High Quantum Vulnerable
RC6-512 Not FIPS-approved Low (Quantum Safe) Quantum Resistant
RC6-1024 Not FIPS-approved Low (Quantum Safe) Quantum Resistant
Rijndael-128 Not FIPS-approved High Quantum Vulnerable
Rijndael-192 Not FIPS-approved High Quantum Vulnerable
Rijndael-256 Not FIPS-approved Low (Quantum Safe) Quantum Resistant
IDEA-128 Not NIST-approved / Obsolete Critical Quantum Vulnerable
ARIA-128 Not FIPS-approved High Quantum Vulnerable
ARIA-192 Not FIPS-approved High Quantum Vulnerable
ARIA-256 Not FIPS-approved Low (Quantum Safe) Quantum Resistant
ARIA-128-CBC Not FIPS-approved High Quantum Vulnerable
ARIA-192-CBC Not FIPS-approved High Quantum Vulnerable
ARIA-256-CBC Not FIPS-approved Low (Quantum Safe) Quantum Resistant
ARIA-128-CTR Not FIPS-approved High Quantum Vulnerable
ARIA-192-CTR Not FIPS-approved High Quantum Vulnerable
ARIA-256-CTR Not FIPS-approved Low (Quantum Safe) Quantum Resistant
ARIA-128-GCM Not FIPS-approved High Quantum Vulnerable
ARIA-192-GCM Not FIPS-approved High Quantum Vulnerable
ARIA-256-GCM Not FIPS-approved Low (Quantum Safe) Quantum Resistant
ARIA-128-CCM Not FIPS-approved High Quantum Vulnerable
ARIA-192-CCM Not FIPS-approved High Quantum Vulnerable
ARIA-256-CCM Not FIPS-approved Low (Quantum Safe) Quantum Resistant
RC6-128 Not FIPS-approved Critical Quantum Vulnerable
RC6-192 Not FIPS-approved High Quantum Vulnerable
RC6-256 Not FIPS-approved Low (Quantum Safe) Quantum Resistant
Hashing
Algorithm / Variant NIST/FIPS Status (FIPS/SP) PQC Severity PQC Readiness
MD5 Deprecated / Legacy (FIPS 180-4) Critical Quantum Vulnerable
MD4 Deprecated / Legacy (FIPS 180-4) Critical Quantum Vulnerable
MD2 Deprecated / Legacy (FIPS 180-4) Critical Quantum Vulnerable
SHA-0 Deprecated / Legacy Critical Quantum Vulnerable
SHA-1 Deprecated / Legacy (FIPS 180-4) Critical Quantum Vulnerable
SHA-224 Approved (FIPS 180-4) High Quantum Vulnerable
SHA-256 Approved (FIPS 180-4) Low (Quantum Safe) Quantum Resistant
SHA-384 Approved (FIPS 180-4) Low (Quantum Safe) Quantum Resistant
SHA-512 Approved (FIPS 180-4) Low (Quantum Safe) Quantum Resistant
SHA-512/224 Approved (FIPS 180-4) High Quantum Vulnerable
SHA-512/256 Approved (FIPS 180-4) Low (Quantum Safe) Quantum Resistant
SHA3-224 Approved (FIPS 202 / SP 800-185) Low (Quantum Safe) Quantum Resistant
SHA3-256 Approved (FIPS 202 / SP 800-185) Low (Quantum Safe) Quantum Resistant
SHA3-384 Approved (FIPS 202 / SP 800-185) Low (Quantum Safe) Quantum Resistant
SHA3-512 Approved (FIPS 202 / SP 800-185) Low (Quantum Safe) Quantum Resistant
RIPEMD-128 Not FIPS-approved Critical Quantum Vulnerable
RIPEMD-160 Not FIPS-approved Critical Quantum Vulnerable
RIPEMD-256 Not FIPS-approved High Quantum Vulnerable
RIPEMD-320 Not FIPS-approved High Quantum Vulnerable
Whirlpool Not FIPS-approved High Quantum Vulnerable
Tiger Not FIPS-approved High Quantum Vulnerable
BLAKE-224 Not Approved (SHA-3 competition finalist, not standardized) High Quantum Vulnerable
BLAKE-256 Not Approved (SHA-3 competition finalist, not standardized) High Quantum Vulnerable
BLAKE-384 Not Approved (SHA-3 competition finalist, not standardized) Low (Quantum Safe) Quantum Resistant
BLAKE-512 Not Approved (SHA-3 competition finalist, not standardized) Low (Quantum Safe) Quantum Resistant
BLAKE2s-128 Standardized (RFC 7693, not NIST-approved) Critical Quantum Vulnerable
BLAKE2s-160 Standardized (RFC 7693, not NIST-approved) Critical Quantum Vulnerable
BLAKE2s-224 Standardized (RFC 7693, not NIST-approved) High Quantum Vulnerable
BLAKE2s-256 Standardized (RFC 7693, not NIST-approved) High Quantum Vulnerable
BLAKE2b-224 Standardized (RFC 7693, not NIST-approved) High Quantum Vulnerable
BLAKE2b-256 Standardized (RFC 7693, not NIST-approved) High Quantum Vulnerable
BLAKE2b-384 Standardized (RFC 7693, not NIST-approved) Low (Quantum Safe) Quantum Resistant
BLAKE2b-512 Standardized (RFC 7693, not NIST-approved) Low (Quantum Safe) Quantum Resistant
BLAKE3 Not Approved (IETF draft, not standardized by NIST) High Quantum Vulnerable
KMAC128 Approved (SP 800-185) Low (Quantum Safe) Quantum Resistant
KMAC256 Approved (SP 800-185) Low (Quantum Safe) Quantum Resistant
Skein-256-128 Not Approved (SHA-3 competition finalist, not standardized) Critical Quantum Vulnerable
Skein-256-160 Not Approved (SHA-3 competition finalist, not standardized) Critical Quantum Vulnerable
Skein-256-224 Not Approved (SHA-3 competition finalist, not standardized) High Quantum Vulnerable
Skein-256-256 Not Approved (SHA-3 competition finalist, not standardized) High Quantum Vulnerable
Skein-512-224 Not Approved (SHA-3 competition finalist, not standardized) High Quantum Vulnerable
Skein-512-256 Not Approved (SHA-3 competition finalist, not standardized) High Quantum Vulnerable
Skein-512-384 Not Approved (SHA-3 competition finalist, not standardized) Low (Quantum Safe) Quantum Resistant
Skein-512-512 Not Approved (SHA-3 competition finalist, not standardized) Low (Quantum Safe) Quantum Resistant
Skein-1024-384 Not Approved (SHA-3 competition finalist, not standardized) Low (Quantum Safe) Quantum Resistant
Skein-1024-512 Not Approved (SHA-3 competition finalist, not standardized) Low (Quantum Safe) Quantum Resistant
Skein-1024-1024 Not Approved (SHA-3 competition finalist, not standardized) Low (Quantum Safe) Quantum Resistant
Hashing Protocols
Protocol NIST / FIPS Status Quantum Status PQC Severity
TLS 1.0 Not Approved (deprecated, RFC 2246) Quantum Vulnerable Critical
TLS 1.1 Not Approved (deprecated, RFC 4346) Quantum Vulnerable Critical
SSH 1.0 Not Approved, obsolete Quantum Vulnerable Critical
SSL 2.0 Not Approved (deprecated, RFC 6176) Quantum Vulnerable Critical
SSL 3.0 Not Approved (deprecated, RFC 6101) Quantum Vulnerable Critical
TLS 1.2 Approved Depend on cipher suite strength
TLS 1.3 Approved Depend on cipher suite strength
Note: Protocol severity is based on key exchange and authentication because those are the parts quantum computers will break first.

Service Binding Information

The Service Binding field captures how a detected service is bound to the network.
It identifies the IP address, port, and (if applicable) the hostname that define where and how the service is listening for incoming connections.
Component Description
Binding IP Address The network interface (IPv4 or IPv6) on which the service listens.
Port Number The specific communication port assigned to the service.
Hostname / Server Name (optional) The logical name or virtual host defined in the service configuration.
Binding Meaning
127.0.0.1 Service listens only on the same host (local).
0.0.0.0 Service listens on all available IPv4 interfaces (wildcard).
[::] Service listens on all available IPv6 interfaces (wildcard).
Specific IP (e.g., 172.16.7.1) Service listens only on that network interface.

If a service is configured to listen on both IPv4 and IPv6 interfaces simultaneously (for example, 0.0.0.0:443 and [::]:443), the platform denotes this condition with an asterisk (*) in the Service Binding field.

This indicates that the service is dual-stack listening on both IPv4 and IPv6 addresses,
  • Hostnames are extracted from service configurations (e.g., server_name, ServerName, or VirtualHost).
  • If separate hostnames are defined per address family, both bindings are recorded individually.

Dashboards & Migration Guidance

As part of the Configuration PQC Readiness Report, the platform provides dashboards and guided actions to help you understand your cryptographic posture and plan your migration toward post-quantum cryptography.

Dashboards

What it shows:
  • PQC Score: An overall readiness score (0–100) calculated based on protocols, libraries, ciphers, and certificates
  • Total Endpoints Detected: All servers, APIs, and devices with cryptographic configurations
  • Total Applications Detected: Applications and services discovered
  • Quantum Readiness by Library: Percentage of libraries that are PQC-ready, classical-only, or outdated
  • Quantum Readiness by Protocol: Breakdown of TLS/SSL protocol usage across environments
  • Risk Levels: Distribution of Critical, High, Medium, Low, and Unknown crypto risks
  • Key Exchange & Authentication Readiness: Current use of RSA, ECDHE, hybrid, or PQC-based mechanisms.
Why it matters:

Dashboards provide a centralized view of cryptographic assets across the enterprise. They highlight legacy exposure, quantify PQC readiness, and help prioritize which applications or endpoints should be addressed first. Without visibility at this level, PQC migration planning is fragmented and incomplete.

Migration Guidance

What it shows:
Recommended steps to transition configurations and applications toward PQC readiness
  • Retire legacy protocols (SSLv2/3, TLS 1.0/1.1) and enforce TLS 1.3.
  • Replace weak or quantum-vulnerable ciphers with strong classical and prepare for hybrid
  • Upgrade cryptographic libraries to PQC-supported versions
  • Re-issue bound certificates with stronger keys, and plan for hybrid/PQC certificates
  • Eliminate RSA/ECC static key exchanges and adopt ephemeral or hybrid key exchanges.
Why it matters:
  • Ensures long-term security of sensitive data against “store now, decrypt later” attacks
  • Reduces risk of sudden breakage or compliance failure when PQC becomes mandatory
  • Provides a clear roadmap from today’s classical cryptography to quantum-resistant standards.
Actions:
  • Use the PQC Score as a baseline to set targets for improvement
  • Prioritize High-risk items (legacy protocols, weak certificates) first, as they most impact scoring
  • Recalculate PQC Score regularly to track progress and demonstrate readiness improvements over time.