Post-quantum cryptography (PQC) planning often focuses on protecting encrypted data, but authentication systems must also evolve. Certificates, trust anchors, PKI services, applications, devices, and hardware security modules may all be affected by new algorithms and larger certificate chains.

Microsoft’s Post-Quantum Cryptography (PQC) Transport Layer Security (TLS) Pilot Program helps eligible certificate authorities evaluate interoperability and operational readiness in controlled environments. Organizations should begin now by inventorying certificate dependencies, assessing vendor roadmaps, identifying long-lived infrastructure, and creating non-production test environments. Early testing can surface compatibility and process gaps before post-quantum authentication is required at scale.

By the end of this article, security leaders, public key infrastructure (PKI) administrators, and architects will understand the key certificate dependencies, migration risks, and practical first steps for post-quantum authentication readiness.

Why post-quantum authentication presents a different challenge

Much of the current PQC readiness discussion focuses on confidentiality and the ‘harvest now, decrypt later’ risk, in which adversaries collect encrypted data today with the expectation that future quantum computers could decrypt it.

Authentication introduces a different set of challenges.

While confidentiality protections primarily focus on safeguarding encrypted communications, authentication depends on a broad ecosystem of technologies and trust relationships. Certificates and private keys must be issued, distributed, stored, validated, renewed, and managed across diverse environments and vendors. Changes to cryptographic algorithms can therefore have implications that extend beyond cryptographic correctness into operational processes, interoperability, and infrastructure readiness.

Organizations frequently understand where TLS protects their communications. Fewer organizations have a complete inventory of every system that issues, validates, stores, distributes, or depends on certificates.

As the industry moves toward post-quantum authentication, security teams will need greater visibility into those dependencies.

Why organizations should begin preparing now

The transition to post-quantum authentication is unlikely to be a single technology upgrade.

Enterprise environments often contain decades of accumulated infrastructure, including internally managed PKI deployments, embedded devices, operational technology, security appliances, custom applications, third-party services, and hardware-backed trust systems. Some of these technologies may have long deployment lifecycles, fixed cryptographic assumptions, or operational constraints that are not immediately visible until testing begins.

The challenge facing organizations is not that post-quantum standards are unavailable. Rather, it is understanding how proposed post-quantum certificate hierarchies interact with the systems and processes already deployed across their environments.

Testing helps answer questions such as:

• Can existing applications correctly process and validate post-quantum certificates?
• How do larger post-quantum certificates and certificate chains affect handshake size, performance, storage, transmission, and inspection limits?
• Do enterprise PKI workflows require changes to accommodate new algorithms?
• Are network monitoring, inspection, or certificate-management systems prepared for post-quantum authentication?
• Are hardware security modules and other cryptographic infrastructure components ready to support future certificate requirements?
• What hidden dependencies exist within supply chains, vendors, and third-party services?

In many cases, organizations may not yet know which of these questions are most relevant to their environments. Identifying those unknowns is one of the primary reasons ecosystem testing is important today.

Microsoft’s perspective on readiness

Post-quantum authentication readiness requires validating how certificate chains, platforms, and operational processes behave together.

The goal is not simply to determine whether a certificate can be issued or validated. The goal is to identify interoperability, compatibility, performance, and operational challenges before post-quantum authentication must be deployed at scale.

Organizations should view post-quantum readiness as a multi-year planning effort rather than a future migration project. Security leaders who begin inventorying dependencies, assessing vendor readiness, and testing interoperability now will be better positioned to make informed decisions as standards, platform support, and industry requirements continue to evolve.

Testing the future certificate ecosystem

To help the ecosystem gain practical experience with post-quantum authentication, Microsoft launched the PQC TLS Pilot Program on August 27, 2026.

The pilot enables approved certificate authorities in good standing with the Microsoft Trusted Root Program to evaluate PQC TLS roots and certificate issuance using quantum-resilient Module-Lattice-Based Digital Signal Algorithm, ML-DSA-87.

The program is intended to create a controlled environment where participants can evaluate interoperability, compatibility, performance, and operational considerations associated with post-quantum certificate hierarchies.

Certificates issued through the pilot are not publicly trusted and are intended solely for interoperability and ecosystem-readiness testing in closed environments, custom applications, and enterprise testbeds. They must not be used for production trust scenarios or public-facing websites. ML-DSA support remains limited and evolving during the pilot and should not be relied upon for production use.

According to the Microsoft Trusted Root Program Annoucement, the August 2026 release added seven pilot roots operated by ComSign, DigiCert, HARICA, IdenTrust Services, Sectigo, Shanghai Electronic Certification Authority, and SSL.com.

The pilot will continue with rolling admissions through the end of 2026, providing additional opportunities for eligible certificate authorities participating in the Microsoft Trusted Root Program to join. Organizations that participate in the Microsoft Trusted Root Program and are interested in evaluating post-quantum authentication readiness should review the PQC TLS Pilot Program requirements and application process through the https://aka.ms/rootcert. The pilot provides eligible certificate authorities with an opportunity to test interoperability, operational processes, and ecosystem readiness ahead of broader post-quantum authentication adoption.

The objective is not to validate a predetermined outcome. It is to help the certificate ecosystem discover where modernization, testing, and operational improvements may be required before post-quantum authentication can be adopted broadly.

Expanding end-to-end testing

On supported and appropriately configured Windows 11 systems, ML-DSA certificates can be evaluated in the pilot’s controlled, non-production testing scenarios. Support begins with the July 28, 2026 updates: KB5101681 (OS Build 28000.2608) for 26H1 and KB5101684 (OS Builds 26200.8973 and 26100.8973) for 25H2.

ML-DSA certificates can also be used with Secure Channel (Schannel) in supported scenarios. Confirm the applicable Windows and Schannel platform requirements before testing.

Together, Microsoft platform support and the PQC TLS Pilot Program provide a controlled way to identify application incompatibilities, certificate-size constraints, performance effects, and operational workflow gaps before they affect production environments.

What organizations can do today

Organizations do not need to wait for broad industry adoption to begin preparing for post-quantum authentication.

Security leaders, PKI administrators, and architects can begin by:

1. Inventory certificate-dependent systems. Identify applications, services, devices, appliances, and infrastructure that depend on certificates for authentication, trust establishment, or lifecycle management.

2. Map trust relationships.

Document both public and private PKI environments, including internal certificate hierarchies, trust anchors, device authentication systems, and externally managed certificates.

3. Assess vendor readiness.

Engage certificate providers, PKI vendors, hardware security module (HSM) providers, software vendors, and platform providers to understand their post-quantum roadmaps and testing capabilities.

4. Identify long-lived infrastructure.

Pay particular attention to systems with lengthy upgrade cycles, including embedded devices, appliances, operational technology environments, and security infrastructure.

5. Develop a safe testing strategy.

Establish non-production environments where post-quantum certificate hierarchies can be evaluated for interoperability, performance, and operational impacts.

6. Build a multi-year transition roadmap.

Treat post-quantum authentication readiness as a program rather than a project. Assign owners, sequence dependencies, and use test results to prioritize modernization work before future requirements emerge.

Organizations interested in testing should consult their certificate provider about whether it participates in the pilot and whether it offers testing opportunities appropriate for their environment.

If your certificate provider participates in the Microsoft Trusted Root Program but is not currently part of the pilot, consider encouraging them to participate through the program’s admissions process.

Looking ahead

Post-quantum authentication will require coordinated changes across certificate authorities, platforms, software, hardware, and enterprise environments. Organizations that begin testing trust infrastructure and certificate dependencies now will be better positioned to reduce future migration risk and strengthen readiness for a quantum-resistant future.

Learn more

• PQC TLS Pilot Program Requirements
• Microsoft Trusted Root Program Announcements
• New Windows Features to Secure Today’s Data in a Post-Quantum World | Microsoft Community Hub
• ASP.NET, Kestrel and Schannel GA with TLS 1.3 Post-Quantum Cryptography
• Quantum-safe security: Progress towards next-generation cryptography
• Microsoft’s quantum-resistant cryptography is here | Microsoft Community Hub
• Post-Quantum Cryptography APIs Now Generally Available on Microsoft Platforms
• For the latest security research from the Microsoft Threat Intelligence community, check out the Microsoft Threat Intelligence Blog.
• To get notified about new publications and to join discussions on social media, follow us on LinkedIn, X (formerly Twitter), and Bluesky.
• To hear stories and insights from the Microsoft Threat Intelligence community about the ever-evolving threat landscape, listen to the Microsoft Threat Intelligence podcast.

The post Post-quantum authentication: Why organizations should start testing certificate ecosystems now appeared first on Microsoft Security Blog.

- AI, supply-chain exposure, quantum computing and geopolitical conflict are testing security programs. Preparing for disruption must become part of day-to-day operations.

The post Four Cyber Threats Harboring Big Plans for the Future appeared first on SecurityWeek.

The new Series A funding round brings the total raised by Quantum Bridge to $16 million. 

The post Quantum Bridge Raises $8 Million for Quantum-Safe Key Distribution Solution appeared first on SecurityWeek.

Migrating your TLS endpoints to Post-quantum cryptography (PQC) starts with understanding your current TLS endpoint inventory and posture. This post introduces the PQC Readiness Scanner — an automated tool that inventories your Application Load Balancer (ALB), Network Load Balancer (NLB), and Amazon API Gateway endpoints and continuously monitors their TLS configurations for PQC readiness. The scanner classifies each endpoint into a three-tier framework that helps prioritize and plan PQC migration.

As quantum computing advances, you need to migrate to quantum-resistant cryptography to protect your data long-term. The PQC Readiness Scanner helps you identify which endpoints to migrate first and tracks your progress across accounts. For web traffic, PQC key exchange algorithms are negotiated only within TLS 1.3. This means quantum-resistant connections require endpoints that support TLS 1.3 and PQC key exchange.

Under the AWS Shared Responsibility Model, AWS secures the infrastructure and enables PQC support across its services. Customers are responsible for configuring their resources to use PQC-capable TLS policies. For AWS-terminated TLS connections—such as those on Application Load Balancer (ALB), Network Load Balancer (NLB), Amazon API Gateway, and Amazon CloudFront—customers choose the security policy (an AWS-managed configuration defining supported TLS protocol versions and cipher suites for a listener) that determines TLS version and cipher suite, key exchange, and authentication algorithm support.

The automated PQC Readiness Scanner for AWS-terminated TLS endpoints is built using AWS Config conformance packs. A conformance pack is a collection of AWS Config rules and remediation actions that can be deployed as a single entity in an account and a Region or across an organization in AWS Organizations.

The PQC Readiness Scanner deploys AWS Config rules using a conformance pack to evaluate the security policy on each endpoint. Based on the evaluation, each resource is classified into a three-tier readiness framework that prioritizes migration actions needed to achieve PQ-ready TLS.

The PQC Readiness Scanner performs two checks per resource:

1. Does the endpoint use a PQ-ready security policy?
2. Does the endpoint support legacy TLS 1.0 or 1.1?

Each check returns COMPLIANT or NON_COMPLIANT status with specific policy recommendations.

PQC requires endpoints to support TLS 1.3 and use PQC key exchange algorithms. The three-tier framework helps you interpret findings and prioritize fixes. The goal is to have TLS 1.3 with PQC key exchange enabled on the endpoints. However, achieving this requires maintaining backward compatibility with clients.

• Tier 1 represents the strongest security using only TLS 1.3 with PQC key exchange. These resources already meet the target state.
• Tier 2 represents a backward-compatible PQ-ready configuration. Endpoints support both TLS 1.2 and TLS 1.3, with PQC key exchange negotiated on TLS 1.3 connections. Migration priority is low because these resources already provide quantum-resistant protection for clients that support TLS 1.3, while maintaining TLS 1.2 compatibility for legacy clients. Migrate to Tier 1 when client-side analysis confirms that the connecting clients support TLS 1.3 with PQC key exchange.
• Tier 3 covers resources that aren’t PQ-ready. This includes endpoints without TLS 1.3 support, endpoints with TLS 1.3 but without PQC key exchange policies. These resources require immediate attention.

The scanner evaluates the following AWS edge services that terminate TLS connections on behalf of your applications.

• Edge services:
  • Application Load Balancer (ALB), Network Load Balancer (NLB) listeners with HTTPS, TLS, and TCP SSL protocols are evaluated.
  • API Gateway REST APIs are evaluated for AWS Regional and private endpoints along with API Gateway HTTP APIs (v2) and WebSocket APIs (v2).
• Excluded edge services:
  • CloudFront distributions are excluded from the PQC readiness scope because TLS 1.3 with hybrid post-quantum key exchange is automatically enabled across existing CloudFront TLS security policies for viewer-to-edge connections. No customer action is required for inbound (viewer-facing) PQC on CloudFront.
• Recommended approach for Classic load balancer:
  • For Classic Load Balancers, AWS recommends migrating to ALB or NLB. Classic Load Balancers don’t support TLS 1.3 or PQC key exchange and can’t be made PQ-ready.

AWS Config enables continuous monitoring and evaluation. Conformance packs enable organization-wide deployment. AWS Lambda is a serverless compute service that runs code to perform security policy evaluation based on the AWS Config rules. AWS Serverless Application Model (AWS SAM) is an open source framework used for deploying the AWS Lambda functions.

Figure 1: PQC readiness solution architecture

The PQC Readiness Scanner conformance pack implements four custom AWS Config rules powered by two Lambda functions:

Before deploying the solution, you need:

• AWS Command Line Interface (AWS CLI) configured with appropriate permissions

  aws configure
  aws sts get-caller-identity  # Verify

• Python 3.12 installed. The Lambda runtime requires this version.

  python3 --version  # Should show 3.12.x

• AWS SAM CLI installed (Installation Guide)

  pip install aws-sam-cli
  
  # Verify
  sam --version

• AWS Config enabled in your target AWS Region.
  • Configure it to record (This step is not needed if your accounts are recording all resources by default)
    • AWS::ElasticLoadBalancingV2::LoadBalancer
    • AWS::ApiGateway::RestApi
    • AWS::ApiGatewayV2::Api resource types.
  • Enable via AWS Config Console → Recorder → Recording Strategy → Select specific resource types (Follow the steps in manual setup for AWS Config recording strategy for specific resource types)

Deploy the PQC Readiness Config Scanner in three phases. Complete deployment commands and configuration details are available in the GitHub repository. The Lambda functions must be deployed first because the conformance pack references their ARNs as parameters. See the GitHub repository for details.

1. Clone and Build:

   git clone https://github.com/aws-samples/sample-PQC-Readiness-using-AWS-Config.git
   
   cd sample-PQC-Readiness-using-AWS-Config/installation
   
   sam build

2. Deploy to One or More Regions:

   # Make script executable (first time only)
   chmod +x deploy-per-regions.sh
   
   # Deploy to a single region
   ./deploy-per-regions.sh us-east-1
   
   # Deploy to multiple regions
   ./deploy-per-regions.sh us-east-1 us-west-2 eu-west-1

   

   Figure 2: Type y and continue if you have enabled AWS Config recording for these resources or its by default recording all resources.

3. The script automatically:
   • Deploys Lambda functions via SAM
   • Deploys conformance pack (creates Config rules)
   • Verifies deployment success
   • Provides clear status messages

The deployment creates two Lambda functions that perform PQ-ready and legacy TLS checks. It provisions IAM roles with least-privilege permissions for ELB, ALB, NLB, and API Gateway describe operations. Lambda permissions allow AWS Config to invoke the functions.

Figure 3: Example screen-print of what a successful deployment looks like.

For organization-wide deployment across multiple AWS accounts, use CloudFormation StackSets to deploy Lambda functions to each account.

Important Constraint: AWS Config CUSTOM_LAMBDA rules require the Lambda function to exist in the same account as the Config rule. You cannot use a centralized Lambda in one account to evaluate resources in other accounts.

Prerequisite: Shared S3 Bucket

Before packaging, create an S3 bucket accessible by each target account in your organization. This bucket will host the Lambda deployment artifacts that CloudFormation StackSets pulls into each member account.

# Create the shared S3 bucket (run from management/central account)
aws s3 mb s3://<your-org-shared-bucket> --region us-east-1

Grant read access to the target accounts using one of the following options:

aws s3api put-bucket-policy \
  --bucket <your-org-shared-bucket> \
  --policy '{
    "Statement": [
      {
        "Sid": "BucketOwnerFullAccess",
        "Effect": "Allow",
        "Principal": {
          "AWS": "arn:aws:iam::<bucket-owner-account-id>:root"
        },
        "Action": "s3:*",
        "Resource": [
          "arn:aws:s3:::<your-org-shared-bucket>",
          "arn:aws:s3:::<your-org-shared-bucket>/*"
        ]
      },
      {
        "Sid": "CrossAccountReadAccess",
        "Effect": "Allow",
        "Principal": {
          "AWS": [
            "arn:aws:iam::<account-id-1>:root",
            "arn:aws:iam::<account-id-2>:root"
          ]
        },
        "Action": ["s3:GetObject", "s3:ListBucket"],
        "Resource": [
          "arn:aws:s3:::<your-org-shared-bucket>",
          "arn:aws:s3:::<your-org-shared-bucket>/*"
        ]
      }
    ]
  }'

Replace <account IDs> with the AWS account IDs where StackSets will deploy the Lambda functions.

Note: The bucket must be in the same region as the StackSet deployment regions. For multi-region deployments, create one bucket per region and run sam package separately for each.

Step 1: Build and Upload Lambda Packages to S3

Run the packaging script from the installation/ directory:

cd installation

# Make script executable (first time only)
chmod +x deploy-stacksets.sh

# Build, package, upload to S3, and generate resolved template
./deploy-stacksets.sh <your-org-shared-bucket>

This script automatically:

• Builds Lambda functions using SAM
• Creates ZIP packages
• Uploads ZIPs to the shared S3 bucket
• Generates packaged-template.yaml with S3 values baked in (no parameters needed at deploy time)

Figure 4: Sample script output of successful upload of the lambda packages to S3 bucket

Step 2: Deploy Lambda Functions via StackSets

Run the following from the management account (or delegated admin account):

# Create StackSet (--region sets the StackSet "home region" where it is managed)
aws cloudformation create-stack-set \
  --stack-set-name pqc-readiness-lambda-functions \
  --template-body file://packaged-template.yaml \
  --capabilities CAPABILITY_IAM \
  --permission-model SERVICE_MANAGED \
  --auto-deployment Enabled=true,RetainStacksOnAccountRemoval=false \
  --region us-east-1

# Deploy stack instances to member accounts
# --regions = target regions where Lambda functions are deployed in member accounts
# --region  = must match the StackSet home region above
aws cloudformation create-stack-instances \
  --stack-set-name pqc-readiness-lambda-functions \
  --deployment-targets OrganizationalUnitIds=ou-xxxx-xxxxxxxx \
  --regions us-east-1 \
  --region us-east-1

Important — StackSet home region vs deployment regions:

• --region (on each CLI command) = the StackSet home region where the StackSet resource lives. Subsequent operations (describe, update, delete) must specify this same region.
• --regions (on create-stack-instances) = the deployment target region(s) where stack instances are created in member accounts.
• These are independent values. Specify --region explicitly to avoid accidental deployment to your CLI’s default region.

Note: SERVICE_MANAGED StackSets must be created from the management or delegated admin account. The management account itself is excluded from stack instance deployments — use deploy-per-regions.sh separately if you need the scanner in the management account.

Step 3: Deploy Organization Conformance Pack

aws configservice put-organization-conformance-pack \
  --organization-conformance-pack-name pqc-legacy-tls-compliance \
  --template-body file://conformance-packs/pqc-legacy-tls-conformance-pack.yaml

This creates Config rules in each member account that reference their local Lambda functions.

The three-tier system provides PQC migration priorities:

High priority – Tier 3 (not PQ-ready):

• Target: Resources without PQC support. This includes endpoints not using PQ-ready security policies, endpoints that still allow TLS 1.0 or 1.1.
• Action: Upgrade to a PQ-ready policy containing PQ in its name, such as those ending with -PQ-2025-09 (see Elastic Load Balancing security policies documentation for the full list).
• Important: Before upgrading to a PQ-ready policy, audit your client TLS versions. PQ-ready policies require TLS 1.3 support; legacy clients that only support TLS 1.2 or earlier will fail to negotiate a connection. Start with a Tier 2 backward-compatible policy (which supports both TLS 1.2 and 1.3 with PQC), monitor connection logs for TLS negotiation failures, and only move to a Tier 1 TLS 1.3-only policy after confirming that your clients support TLS 1.3 with PQC key exchange.
• Risk: Endpoints don’t support post-quantum cryptography for data in transit. Legacy TLS protocols are vulnerable to current cryptographic attacks.

Low priority – Tier 2 (PQ-ready, backward compatible):

• Target: Resources using TLS 1.3 + PQ-ready policies that also support TLS 1.2 for backward compatibility.
• Action: Consider TLS 1.3-only policies when client compatibility analysis confirms connecting clients support TLS 1.3.
• Risk: Minimal. These resources already support PQ-TLS with TLS 1.3 connections. TLS 1.2 and earlier fallback maintains backward compatibility, which might indicate some clients aren’t negotiating in PQ-TLS. Remediation is to monitor logs, identify the volume of these connections and clients and plan migration for these clients to use TLS 1.3 with PQ-TLS.

No action – Tier 1 (PQ-ready, optimal):

• Target: Resources using TLS 1.3 only with PQC key exchange: These resources meet the target state. No migration needed.

In each member account, navigate to AWS Config Console in the deployed region.

Go to AWS Config → Conformance packs and look for:

OrgConformsPack-pqc-legacy-tls-compliance-

Note: Organization conformance packs are prefixed with OrgConformsPack- and have a random suffix appended (e.g., OrgConformsPack-pqc-legacy-tls-compliance-gyv22je0).

Figure 5: PQC Conformance Pack Compliance Score is the percentage of the number of compliant rule-resource

Click the conformance pack to see an overall compliance summary across all 4 rules.

Go to AWS Config → Rules and find 4 rules with prefix pqc-:

• pqc-elb-pqc-compliance-conformance-pack-
• pqc-elb-legacy-tls-conformance-pack-
• pqc-apigateway-pqc-compliance-conformance-pack-
• pqc-apigateway-legacy-tls-conformance-pack-

Click any rule to view:

• Compliant vs non-compliant resource counts
• Detailed annotations for each resource
• Resource ARNs and current security policy configurations

Figure 6: Visibility into Config rules status inside the conformance pack

Figure 7: Sample image of the config rule findings and annotation describing the migration guidance based on 3-tier classification.

After deploying the PQC Readiness Scanner, you gain visibility into TLS posture across AWS edge services, which reduces manual configuration reviews. The tier system provides specific upgrade recommendations so teams can understand next steps without cryptographic expertise. The scanner automatically detects configuration changes to help new deployments maintain readiness standards. Built-in AWS Config reporting supports audit requirements and demonstrates measurable progress toward PQC readiness.

Deploy the PQC Readiness Scanner and review your results with PQC Readiness Scanner. Start migration with high priority Tier 3 resources and monitor progress across your accounts using AWS Config aggregators.

• GitHub repository: PQC Readiness Config Scanner
• AWS Config documentation: Custom Rules with Lambda
• AWS SAM documentation: Serverless Application Model
• PQC migration planning: NIST Post-Quantum Cryptography Standards
• PQC migration planning: AWS post-quantum cryptography migration plan

If you have feedback about this post, submit comments in the Comments section below. If you have questions about this post, start a new thread on AWS Config re:Post or contact AWS Support.

Accelerating the Migration to the Post-Quantum Era

The promise of quantum computing brings an unprecedented paradox. While it will unlock revolutionary breakthroughs in science, materials discovery and medicine, it simultaneously poses an existential threat to the mathematical foundations of modern cybersecurity.

For decades, the global economy has relied on public key cryptography to safeguard everything from personal privacy to national security. This cryptography is built on mathematical problems that are computationally infeasible for classical computers to solve but that quantum computers can solve efficiently, rendering today’s cryptographic protocols obsolete.

Using Shor’s algorithm, a sufficiently powerful quantum computer could factor the large prime numbers that underpin public key cryptography, in minutes. These are tasks that would take today’s most advanced supercomputers a millennium to crack. This capability would effectively turn our strongest digital defenses into open doors, creating a period of vulnerability leading up to Q-Day – the day today’s encryption is broken.

The Migration Crisis: Why Traditional Strategies Fail

For CISOs and technical leaders, the transition to post-quantum cryptography (PQC) is not a simple patch-and-deploy exercise. It is a multiyear transformation that requires updating cryptography across every device, application, certificate and infrastructure component in the enterprise.

Most enterprises today are constrained by cryptographic debt – years of accumulated, undocumented and deprecated encryption protocols buried deep within legacy applications, third-party software libraries and unmanaged IoT devices. This creates a vast and largely invisible attack surface that traditional vulnerability scanners were never designed to detect.

The challenge is compounded by the absence of a unified source of truth. Existing tools offer a fragmented "outside-in" view of the environment. They may identify devices on the network, but they lack visibility into cryptographic libraries embedded within live traffic. Without a real-time Cryptographic Bill of Materials (CBOM), security teams are forced to rely on manual, point-in-time audits that become outdated almost immediately. Spreadsheets cannot scale to this problem.

This visibility gap makes it impossible to prioritize remediation, leaving sensitive data exposed to harvest now, decrypt later (HNDL) attacks. In these attacks, adversaries intercept and store encrypted data today with the intent of unlocking it once quantum computing capabilities mature.

Operationally, traditional migration approaches are equally unworthy. Manually updating cryptography across thousands of global endpoints and branch offices often requires disruptive rip and replace strategies that threaten uptime and demand specialized expertise that is in extremely short supply. Organizations need a way to bridge today’s classical infrastructure with a quantum-resilient future without disrupting business operations or exhausting IT resources.

At Palo Alto Networks, we believe global enterprises cannot afford to wait. Our new Quantum-Safe Security solution is designed to remove these operational roadblocks by making cryptographic discovery, risk assessment and transition both continuous and actionable. We empower enterprises to gain real-time visibility into cryptographic risk and begin building agentic resilience at enterprise scale by integrating with existing security and infrastructure systems, including security information and event management (SIEM), load balancers, endpoint detection and response (EDR), as well as Application Vulnerability Management (AVM) tools.

The Four Stages of Cryptographic Inventory & Remediation

Palo Alto Networks Quantum-Safe Security is built around four foundational stages.

1. Continuous Discovery through Ecosystem Ingestion

Visibility is the first line of defense, but in a complex enterprise, true visibility requires more than a periodic scan. It requires continuous, high-fidelity ingestion of cryptographic intelligence across the environment.

Our solution acts as a central nervous system for your cryptographic posture, ingesting telemetry and logs directly from PAN-OS NGFW and Prisma® Access, enriched with data from a broad ecosystem of third-party security solutions, simplifying Day 0 onboarding. By leveraging your existing network infrastructure as sensors, we provide a comprehensive view of the cryptographic behavior of all assets without the operational friction of deploying new software.

To eliminate blind spots, we go beyond our own telemetry to ingest critical information from your existing systems you rely on. This includes syncing with configuration management database (CMDB) and asset management platforms to align cryptographic data with business inventories, integrating with EDR and access control solutions to monitor endpoint behavior, and aggregating data from network clouds and log platforms. The result is a unified intelligence layer that reflects how cryptography is actually used across the enterprise.

By synthesizing these data streams, we deliver a multidimensional view of cryptographic exposure:

• Discovery – Identification of every application, user device, infrastructure component and IoT device.
• Behavior – Analysis of traffic metadata, including protocols, key exchange mechanisms, encryption algorithms, hashes, certificates and tunnels.
• Context – Precise attribution of hardware models, cryptographic libraries (such as deprecated OpenSSL versions), and browser versions in use.

2. Risk Assessment & Prioritization

Not all data is created equal, and a successful migration requires a surgical focus on where the exposure is most acute. Our Quantum Safe Security solution quantifies risk by correlating cryptographic strength with business criticality, providing a clear, prioritized view of current risk and where remediation matters most.

Assets are categorized into strategic zones, starting with immediate exposure risks caused by deprecated protocols that are vulnerable to classical exploitation today. From there, the solution addresses long-term harvest now, decrypt later threats. As threat models evolve, the risk engine is designed to expand to emerging vectors like identity and authentication integrity, anticipating risks such as “Trust Now, Forge Later" attacks that could undermine digital trust at scale.

At the same time, the solution validates and tracks quantum-secure assets that have successfully transitioned to post-quantum or hybrid-PQC algorithms. By correlating this intelligence with business criticality and data shelf-life, security leaders can make informed decisions. For example, a crown jewel asset containing data that must remain confidential for a decade or more, is flagged as a high HNDL risk today and elevated to the top of the migration queue.

3. Comprehensive Remediation

Moving from a vulnerable state to quantum resilience is a structured journey. Our comprehensive remediation framework guides organizations through three critical stages, supported by automated workflows and prioritized recommendations at every step.

• Current State to Quantum Ready: The first stage focuses on infrastructure modernization. Using continuous discovery insights, the solution provides hardware and software recommendations required to support next-generation cryptographic protocols. An asset reaches a Quantum Ready state once it has the underlying hardware and OS capabilities to support post-quantum algorithms, even if those protocols are not yet activated.
• Quantum Ready to Quantum-Safe: Transitioning to a Quantum-safe state requires activation and configuration of post-quantum defenses. Our solution provides data configuration and certificate compliance guidance to enable PQC/Hybrid-PQC algorithms to be correctly implemented across the estate.
• Virtual Patching via Cipher Translation: For all current and especially legacy systems or IoT devices that cannot be upgraded, we provide an accelerated path to quantum-safety. Through Cipher Translation, the infrastructure acts as a proxy, providing agentic remediation that reencrypts vulnerable traffic into quantum-safe standards (such as ML-KEM) in real-time at the network edge. This approach instantly moves legacy assets from a high-risk current state to a Quantum-safe posture without a single line of code change.

4. Governance: Continuous Crypto-Hygiene & Global Compliance

Quantum readiness is not a one-time event; it is a strategic enterprise transformation that requires continuous oversight to prevent the re-emergence of vulnerabilities. Our governance framework provides the guardrails for your migration through two critical layers of management:

Continuous Crypto-Hygiene & Ongoing Management: Maintaining high-fidelity visibility is essential to preventing the accumulation of "crypto-debt." Our solution automates real-time mapping of all cryptographic dependencies, ensuring your CBOM remains dynamic and accurate as your environment evolves. Furthermore, we introduce Active Drift Detection, which automatically detects and can even block the use of weak or noncompliant ciphers in real-time, preventing developers or third-party services from accidentally introducing insecure protocols.

Global Crypto-Compliance Enforcement & Reporting: As regulatory pressure from governments (like the US Commercial National Security Algorithm Suite 2.0) mounts, organizations must demonstrate measurable progress. Our solution will provide Automated Framework Auditing, offering continuous, native mapping of your environment against global standards, including NIST, FIPS 140-3, and DORA.

Architecting a Quantum-Resilient Enterprise

The transition to quantum-safe security is far more than a technical upgrade. It represents a fundamental shift in how organizations protect the longevity and integrity of their digital assets. Achieving quantum resilience is a multiyear effort that requires both advanced technology and strategic partnership.

That's why Palo Alto Networks has established Integrated Quantum Practices, bringing together technology, partners and professional services to help organizations navigate the complexity of this transition with confidence. By combining deep cryptographic visibility with intelligent, agentic remediation, organizations can systematically retire their cryptographic debt and build resilience into their security architecture over time.

This proactive approach does more than mitigate emerging risk. It establishes a foundation of digital trust that is resilient against the threats of tomorrow, enabling your most sensitive intellectual property to remain secure for its entire shelf life, even as cryptographic standards evolve.

Secure Your First-Mover Advantage: The Quantum Readiness Assessment

Don’t let the complexity of the quantum transition stall your organization’s progress. Begin your path to resilience with a Quantum Readiness Assessment, a focused engagement to clarify current exposure and identify the most critical areas for action. To go deeper, watch the Quantum-Safe Summit on demand for expert perspectives on cryptographic risk and quantum readiness.

The Palo Alto Networks Quantum-Safe Security solution is expected to be generally available to customers on January 30, 2026, with additional integration enhancements planned for April 2026.

Forward-Looking Statements

This blog contains forward-looking statements that involve risks, uncertainties and assumptions, including, without limitation, statements regarding the benefits, impact or performance or potential benefits, impact or performance of our products and technologies or future products and technologies. These forward-looking statements are not guarantees of future performance, and there are a significant number of factors that could cause actual results to differ materially from statements made in this [blog. We identify certain important risks and uncertainties that could affect our results and performance in our most recent Annual Report on Form 10-K, our most recent Quarterly Report on Form 10-Q, and our other filings with the U.S. Securities and Exchange Commission from time-to-time, each of which are available on our website at investors.paloaltonetworks.com and on the SEC's website at www.sec.gov. All forward-looking statements in this blog are based on information available to us as of the date hereof, and we do not assume any obligation to update the forward-looking statements provided to reflect events that occur or circumstances that exist after the date on which they were made.

The post Introducing Palo Alto Networks Quantum-Safe Security appeared first on Palo Alto Networks Blog.

Quantum computers are coming, with a potential computing power almost beyond comprehension.

The post Cyber Insights 2026: Quantum Computing and the Potential Synergy With Advanced AI appeared first on SecurityWeek.

AI has introduced a transformative era in scientific discovery. In the hands of researchers, innovators, and startups, it is accelerating breakthroughs from advancing medical research to powering new manufacturing capabilities and energy transitions.  

For Microsoft, the real promise of AI emerges when we bring our powerful tools together with problem solvers in local communities. For the past eight years, Microsoft has been sharing knowledge and collaborating with communities to unlock opportunity through Microsoft TechSpark, an economic development, skilling, and community-building program across the US. Since its inception, TechSpark has helped create more than 4,500 jobs and contributed more than $700 million in community funding to support local initiatives. 

Today, we’re announcing a new milestone in our TechSpark program: a pioneering partnership with leading innovation centers—TitletownTech, in partnership with the University of Wisconsin-Madison, and the New Jersey (NJ) AI Hub, in partnership with Princeton University. Together, we’re launching a new model for scientific collaboration that combines the agility of a startup, the expertise of a university, and the technology of a global company.  

Through this partnership, Microsoft will provide the Microsoft Discovery platform to TitletownTech and NJ AI Hub and access to the latest advancements in AI and high-performance computing that promise to accelerate scientific discovery. We believe this kind of alliance is essential to ensure that breakthroughs in science and solutions to global challenges are not confined to a few but shared broadly for the benefit of all.

A new model for scientific discovery 

Researchers and innovators from these organizations will have an opportunity to access Microsoft Discovery, an advanced agentic AI platform designed to accelerate scientific breakthroughs. They will also benefit from the expertise of the Microsoft Discovery and Quantum team, under the leadership of Jason Zander. Currently available only in private preview, this opportunity enables researchers to leverage state-of-the-art AI and high-performance computing to collaborate with a team of specialized AI agents combined with a graph-based knowledge engine to drive scientific outcomes with speed, scale, and accuracy. 

Through Microsoft Discovery, researchers can speed up scientific discovery by analyzing vast amounts of data, simulating experiments, and uncovering new materials and solutions more efficiently. The platform facilitates effective collaboration, bringing together teams of specialized AI agents and human experts for continuous, iterative investigation. This dynamic environment helps organizations refine their knowledge, learn from their results, and innovate in ways that were previously unimaginable. 

What makes this partnership unique is its focus on real breakthroughs in chemistry, life sciences, advanced manufacturing, and AI-driven innovation. Building on years of TechSpark collaboration, this initiative is not just another corporate research and development center or a one-off research grant. Instead, we are creating a shared undertaking, deeply rooted in engagement with local communities and aligned around the promise of AI. By blending the strengths of top research universities with the cutting-edge infrastructure of the NJ AI Hub and TitletownTech Labs and Microsoft’s role as an industry convener, we hope to set the stage for transformative progress. 

Collaborating for real-world impact 

While we are still in the early days of what’s possible, we are dedicated to discovering what can be achieved when our institutions work together to accelerate science and innovation.  

This technology could be a game-changer for environmental challenges like plastic waste. For example, Microsoft Discovery can enable modeling of complex chemical reactions, unlocking new pathways for catalyst design in recycling systems. This would enable more efficient, selective, and controlled recycling processes, fewer costly lab experiments, and faster innovation. In the future, advances like these could empower researchers to turn plastic waste into valuable resources. 

In Microsoft’s own labs, the integration of high-performance computing and AI into Microsoft Discovery is already unlocking new scenarios. For instance, our researchers used Discovery’s advanced AI systems and HPC capabilities to discover a novel sustainable coolant prototype for datacenter immersion cooling—moving from digital discovery to synthesis in just four months. 

Looking ahead 

We are putting the Microsoft Discovery platform into the hands of innovators, like those at TitletownTech and the NJ AI Hub, to fuel innovation and demonstrate real-world impact. 

In the coming weeks, we will work to enable access to Microsoft Discovery for these labs under the private preview, and as we roll out the Discovery platform availability to the public, we will continue to work with these partners and other researchers and universities to ensure we expand opportunity for scientific discovery through AI.  

It’s only with a strong ecosystem that we’ll be able to realize the full potential of Microsoft Discovery, and it’s why we’re working with these partners and others to bring first-party advancements together with leading industry tools and domain expertise. 

With this new chapter for our TechSpark partners, we reaffirm our commitment to championing innovation and discovery alongside the brilliant local innovators across Wisconsin and New Jersey. Together, we look forward to shaping the future of science for everyone.

The post Microsoft TechSpark partners with TitletownTech and the New Jersey AI Hub to accelerate scientific discovery appeared first on Microsoft On the Issues.