<?xml version="1.0" encoding="UTF-8"?>
<rss xmlns:content="http://purl.org/rss/1.0/modules/content/" xmlns:dc="http://purl.org/dc/elements/1.1/" xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#" xmlns:taxo="http://purl.org/rss/1.0/modules/taxonomy/" version="2.0">
  <channel>
    <title>topic PQC Support in Network Access Control</title>
    <link>https://community.cisco.com/t5/network-access-control/pqc-support/m-p/5544485#M600207</link>
    <description>&lt;P&gt;With NIST having finalized FIPS 203 (ML-KEM), 204 (ML-DSA), and 205 (SLH-DSA) in August 2024, we're starting to evaluate our NAC infrastructure for post-quantum readiness and wanted to get some clarity on where ISE currently stands.&lt;/P&gt;&lt;P&gt;I know ISE 3.3 introduced TLS 1.3 for the Admin GUI, and ISE 3.4 extended TLS 1.3 support to EAP-TLS and TEAP-TLS — which is a meaningful step since TLS 1.3 is a prerequisite for any PQC key exchange. What I'm trying to understand is whether ISE has gone further than just enabling TLS 1.3.&lt;/P&gt;&lt;P&gt;Specifically:&lt;/P&gt;&lt;P&gt;1. Does ISE 3.4 or 3.5 support any PQC key exchange mechanisms (KEMs) such as ML-KEM within EAP-TLS or TEAP-TLS sessions? Even a hybrid mode like X25519MLKEM768 (the group now default in Chrome and supported in most modern browsers) would count.&lt;/P&gt;&lt;P&gt;2. Is there any "PQC Ready" or "hybrid" cipher suite language in the ISE roadmap or release documentation that I may have missed? I'm specifically looking for references to KEM algorithms or hybrid TLS groups like X25519MLKEM768 in the context of EAP or RADSec.&lt;/P&gt;&lt;P&gt;3. For RADSec, ISE running TLS 1.3 on the RADIUS-over-TLS channel — is there any plan or existing support for PQC cipher groups on that channel?&lt;/P&gt;&lt;P&gt;Context: TLS 1.3 support on the AAA plane is the necessary first step, but the actual quantum vulnerability is in the key exchange, not the TLS version itself. AES-GCM bulk encryption is already quantum-resistant; it's the asymmetric key exchange (ECDH, RSA) negotiated during the TLS handshake that is exposed to harvest-now-decrypt-later attacks. So the question is specifically about whether ISE can negotiate ML-KEM or hybrid KEM groups during the EAP tunnel setup.&lt;/P&gt;&lt;P&gt;Any input from folks who have dug into the ISE 3.5 security settings or seen anything in the roadmap would be appreciated. TAC references or release note pointers welcome.&lt;/P&gt;</description>
    <pubDate>Fri, 10 Apr 2026 00:34:26 GMT</pubDate>
    <dc:creator>ProjectAdmin9535</dc:creator>
    <dc:date>2026-04-10T00:34:26Z</dc:date>
    <item>
      <title>PQC Support</title>
      <link>https://community.cisco.com/t5/network-access-control/pqc-support/m-p/5544485#M600207</link>
      <description>&lt;P&gt;With NIST having finalized FIPS 203 (ML-KEM), 204 (ML-DSA), and 205 (SLH-DSA) in August 2024, we're starting to evaluate our NAC infrastructure for post-quantum readiness and wanted to get some clarity on where ISE currently stands.&lt;/P&gt;&lt;P&gt;I know ISE 3.3 introduced TLS 1.3 for the Admin GUI, and ISE 3.4 extended TLS 1.3 support to EAP-TLS and TEAP-TLS — which is a meaningful step since TLS 1.3 is a prerequisite for any PQC key exchange. What I'm trying to understand is whether ISE has gone further than just enabling TLS 1.3.&lt;/P&gt;&lt;P&gt;Specifically:&lt;/P&gt;&lt;P&gt;1. Does ISE 3.4 or 3.5 support any PQC key exchange mechanisms (KEMs) such as ML-KEM within EAP-TLS or TEAP-TLS sessions? Even a hybrid mode like X25519MLKEM768 (the group now default in Chrome and supported in most modern browsers) would count.&lt;/P&gt;&lt;P&gt;2. Is there any "PQC Ready" or "hybrid" cipher suite language in the ISE roadmap or release documentation that I may have missed? I'm specifically looking for references to KEM algorithms or hybrid TLS groups like X25519MLKEM768 in the context of EAP or RADSec.&lt;/P&gt;&lt;P&gt;3. For RADSec, ISE running TLS 1.3 on the RADIUS-over-TLS channel — is there any plan or existing support for PQC cipher groups on that channel?&lt;/P&gt;&lt;P&gt;Context: TLS 1.3 support on the AAA plane is the necessary first step, but the actual quantum vulnerability is in the key exchange, not the TLS version itself. AES-GCM bulk encryption is already quantum-resistant; it's the asymmetric key exchange (ECDH, RSA) negotiated during the TLS handshake that is exposed to harvest-now-decrypt-later attacks. So the question is specifically about whether ISE can negotiate ML-KEM or hybrid KEM groups during the EAP tunnel setup.&lt;/P&gt;&lt;P&gt;Any input from folks who have dug into the ISE 3.5 security settings or seen anything in the roadmap would be appreciated. TAC references or release note pointers welcome.&lt;/P&gt;</description>
      <pubDate>Fri, 10 Apr 2026 00:34:26 GMT</pubDate>
      <guid>https://community.cisco.com/t5/network-access-control/pqc-support/m-p/5544485#M600207</guid>
      <dc:creator>ProjectAdmin9535</dc:creator>
      <dc:date>2026-04-10T00:34:26Z</dc:date>
    </item>
    <item>
      <title>Re: PQC Support</title>
      <link>https://community.cisco.com/t5/network-access-control/pqc-support/m-p/5544512#M600209</link>
      <description>&lt;P&gt;1. All of the supported ciphers are documented in the Compatibility Guides for the various ISE versions.&lt;BR /&gt;&lt;A href="https://www.cisco.com/c/en/us/support/security/identity-services-engine/products-device-support-tables-list.html" target="_blank"&gt;https://www.cisco.com/c/en/us/support/security/identity-services-engine/products-device-support-tables-list.html&lt;/A&gt;&lt;/P&gt;&lt;P&gt;2. Roadmap is not discussed in this public forum. This is likely in the roadmap, but any commit or version info cannot be shared.&lt;/P&gt;&lt;P&gt;3. ISE does not support RADSec, it currently only supports RADIUS DTLS (UDP)&lt;/P&gt;</description>
      <pubDate>Fri, 10 Apr 2026 06:21:20 GMT</pubDate>
      <guid>https://community.cisco.com/t5/network-access-control/pqc-support/m-p/5544512#M600209</guid>
      <dc:creator>Greg Gibbs</dc:creator>
      <dc:date>2026-04-10T06:21:20Z</dc:date>
    </item>
  </channel>
</rss>

