Q01: What is the real threat?

A: The threat is that attackers can collect encrypted network data and then break the asymmetric cryptography (RSA/ECC/DH) used to protect bulk data encryption keys (AES) once cryptographically relevant quantum computers come online. This is known as Harvest Now, Decrypt Later (HNDL).

Q02: Do I need to use TLS 1.3 for PQ support?

A: Yes. Earlier versions of TLS, including TLS 1.0, TLS 1.1, and TLS 1.2, do not and will not support post-quantum key establishment.

Q03: Does enabling TLS 1.3 give me hybrid PQ support?

A: No. By default, you will get ‘classic’ crypto algorithms. You must enable the PQ algorithms; this is explained later.

Q04: What Windows OS version must I use to get TLS 1.3 and post-quantum support?

A: TLS Hybrid Key Exchange using ML-KEM groups is available on Windows 11 starting with update KB5089573 for 24H2 and 25H2 and KB5095091 for 26H1.

For Windows Server 2025 use the patch from July 14, 2026-KB5099536 (OS Build 26100.33158)

Q05: What is hybrid crypto in TLS 1.3?

A: Hybrid crypto establishes cryptographic keys by combining elliptic-curve cryptography with post-quantum cryptography, allowing the client and server to use both algorithms during the TLS 1.3 key establishment. It’s a hedge in case the PQ cryptography is broken.

Q06: What crypto is used in hybrid?

A: Like all crypto in TLS, this is flexible; however, the most common hybrid crypto for web browser-based key establishment is X25519_MLKEM768 which combines the classic X25519 Elliptic Curve with post-quantum ML-KEM.

Q07: What is ML-KEM?

A: ML‑KEM (Module-Lattice Key Encapsulation Mechanism) is the new quantum-resistant method for securely establishing cryptographic keys between hosts. It is defined in FIPS 203.

Q08: Is hybrid TLS 1.3 enabled in Windows today?

A: No not by default; you must enable it. If you use Group Policy, you can set the policy there. If the machine does not have GP, then you can use the following from an elevated PowerShell prompt:

Note that -Position 0 is important as it places the hybrid group X25519_MLKEM768 at the top of the preferred group list. If you do not do this, you might not negotiate to the hybrid PQC group.

IMPORTANT: Note that Group Policy will override this setting, so don’t mix-n-match! If you see your group ordering change after calling the PS cmdlet, it's probably GP coming in and overriding the setting. 

Q09: In the prior answer, you used the word ‘group’ what is a group?

A: In TLS 1.3, a "group" is simply the method (or algorithm) that the client and server agree to use to securely establish keys during the connection. Examples include X25519 (the most common Elliptic Curve TLS 1.3 group) or the newer hybrid X25519_MLKEM.

As a side note, the word "group" isn't arbitrary - it comes from the underlying algebra (elliptic-curve groups, finite-field multiplicative groups). It's mathematically precise; it's just opaque to anyone who isn't thinking about group theory! However, ML-KEM isn't built on a group at all - its hardness comes, in part, from lattices.

Q10: Is a group the same as a ciphersuite in TLS 1.3?

A: No, a group is not the same as a ciphersuite in TLS 1.3. The group is how the client and server agree on secret keys. The ciphersuite is how they use secret keys to encrypt and protect the traffic. They work together in a TLS 1.3 handshake, but they are two separate parts

Q11: Are there other groups I should know about?

A: Yes. There are three common hybrid groups; you have already met X25519_MLKEM768, but there is also SecP256r1_MLKEM768 and SecP384r1_MLKEM1024.

Q12: What group should I use?

A: Follow your organization’s cryptographic policy and required assurance profile. For browser interoperability, prefer X25519_MLKEM768 where supported and place it ahead of other groups. For regulated environments, use a hybrid group and implementation permitted by the applicable policy and validated cryptographic module; this may require SecP256r1_MLKEM768 or SecP384r1_MLKEM1024 instead of X25519_MLKEM768.

Q13: If there is TLD 1.3 with hybrid crypto, is there a version that is NOT hybrid?

A: Yes, it’s called ‘pure’, and that is where rather than using ECC+PQC, you use just PQC; for example instead of X25519+MLKEM768, you use only MLKEM768 or MLKEM1024 if CNSA 2.0 compliance is in scope. Some customers may eventually require this. You can read about the MLKEM-only Windows schannel update here August 27, 2026—KB5120998 (OS Builds 26200.9278 and 26100.9278) Preview | Microsoft Support.

Q14: What’s CNSA 2.0?

A: CNSA 2.0, the Commercial National Security Algorithm Suite 2.0, is the NSA's set of quantum-resistant cryptographic algorithm requirements for U.S. National Security Systems. It updates CNSA 1.0 by introducing post-quantum algorithms intended to protect classified and other national-security-sensitive information against both classical and future quantum attacks. It is important because transitioning cryptographic infrastructure takes years, while adversaries can collect encrypted data now and attempt to decrypt it later. Although its formal scope is National Security Systems, CNSA 2.0 also provides vendors and other organizations with a concrete high-assurance target for planning, product development, and post-quantum migration.

The list of algorithms that affect TLS includes:

• Key establishment: ML-KEM-1024 only (not 512, not 768)
• Digital signatures: ML-DSA-87 only (not 44, not 65)
• Hashing: SHA-384 or SHA-512 only
• Symmetric encryption: AES-256 only

Q15: How do I test if my server supports TLS 1.3?

A: See Appendix A.

Q16: How do I test if my server supports TLS 1.3 and PQC?

A: See Appendix B.

Q17: How do I use Wireshark to determine if my server supports TLS 1.3 and PQC?

A: See Appendix C.

Q18: Do both the client and server need to support hybrid PQC TLS?

A: Yes.

Q19: What happens if one side does not support hybrid PQC TLS?

A: If one side does not support hybrid PQC TLS, the connection may still succeed using another mutually supported TLS 1.3 key establishment group, for example X25519, but it will not use hybrid PQC protection. The exact behavior depends on the client, server, and TLS configuration.

Q20: How do I know if my client, such as a browser, supports PQC TLS?

A: Point your application or browser at a tool like this https://pqc.ninja/api/browsertest/ it will output something like:

You can see that the browser and server negotiated to use the X25519_MLKEM768 hybrid group and the browser supports this along with two classic (ie; non-PQC) curves, prime256v1 and secp384r1.

Q21: Are PQC (ML-DSA) certificates required for TLS 1.3?

A: No, not for hybrid PQC key establishment. PQC certificates are a separate part of the post quantum migration and relate to authentication and digital signatures. Hybrid key establishment protects the session key agreement; PQC certificates will protect the certificate signature and authentication path.

Q22: Following the previous question, why does the server still use a classic certificate if the key negotiation is post-quantum?

A: This is by design. We need to secure data in transit first and foremost, since that represents the most immediate quantum threat. An adversary can perform a harvest-now, decrypt-later attack by storing encrypted communications today and waiting until quantum computers are available to decrypt them - any data being transmitted currently needs quantum-safe key exchange to be secure in the future. Authentication, however, does not have that same window of exposure: to perform a successful spoof via certificate misuse, an attacker would need a cryptographically meaningful quantum computer at the time of the session - they do not get to use it later. As we don't have that ability currently, by securing key exchange first we mitigate the most imminent threat while the ecosystem around it (CAs, trust anchors, relying parties, etc.) works towards supporting PQC signatures.

Q23: Is there a performance impact from hybrid PQC TLS?

A: We will provide more stats as they become available, but current details look good; X25519 vs X25519-MLKEM768 is about a 3%-6% latency delta and less than 1% CPU hit using Azure Linux, nginx + OpenSSL + SymCrypt and similar stats using https.sys on Windows Server 2025.

Q24: Should I enable this on internet-facing services first or internal services first?

A: Start with controlled pilots, then prioritize services that protect long-lived or high-value confidential data. Internet-facing services may provide broader coverage, but internal services can be easier to test and control. The right rollout order should balance risk, compatibility, visibility, and operational readiness.

Q25: What logging or telemetry should I capture during testing?

A: Capture the client and server IP addresses, the negotiated key-establishment group, the negotiated cipher suite, and the TLS protocol version for every test connection. Also record whether the handshake succeeded or failed and correlate each result with a timestamp or connection identifier. This makes it possible to confirm that TLS 1.3 and the expected hybrid PQC group were negotiated.

Below is a screen shot from a tool I have on GitHub that shows most of this passively in Windows using schannel and pktmon. The code is here x509cert/schannel-cap.

Appendix A - Testing for TLS 1.3

You can use tools like OpenSSL, PowerShell or a modern browser to test a server to determine if it supports TLS 1.3.

Let’s look at each.

OpenSSL

Use the following from a Windows or Linux command-line, obviously replacing the IP address and port number for your target service.

Success is when you see:

PowerShell 7+

Save the following as Test-Tls13.ps1.

You can call this using positional syntax:

Or using parameters:

Success is indicated by output like this:

Edge and Chrome Browsers

Current versions of Edge and Chrome support hybrid TLS 1.3. After you make a connection to the server, click the ellipsis in the top right (…) -> More Tools -> Developer Tools -> Security.

If you don’t see the security option:

Then click on the + symbol and add the Security tab.

Now you will see the connection details, if you see TLS 1.3, then the server and client are connected with TLS 1.3. In the example below, the connection is also using X25519MLKEM, so the connection is not just using TLS 1.3, it’s using TLS 1.3 in PQ hybrid.

Appendix B – Testing for TLS 1.3 and PQC

The simplest and most reliable way to test a server to determine if it supports TLS 1.3 and PQC, is to use the following OpenSSL command-line:

You will see output like this:

The group information, in this case X25519MLKEM is at the bottom, this indicates that hybrid PQC is in place for this connection.

Appendix C – Wireshark Filtering

Wireshark is commonly used to determine what data is travelling across a network. You can determine if a connection uses hybrid groups using the following steps:

• Start Wireshark,
• Perform some sample network connections (like make an API call or load a page in a browser),
• Stop the collection
• Enter the following in the filter window: tls.handshake.extensions_key_share_group
• Click on the packet of interest and scroll to the Extension: key_share line.

You will see something like this:

The line in this example shows that the connection uses X25519MLKEM768 which is a hybrid PQC group.

Note, you will often see TLS 1.2 used as the protocol version, Wireshark explains why:

The TLS Version field is a deprecated field, so ignore it!

Thanks!

As usual, a big thanks to the people who helped write and edit this document:

• Jessica Krynitsky - Windows Security
• Andrei Popov - Windows Security
• Aabha Thipsay - Windows Security
• Vick Mukherjeee - Azure Security

I'm worried about the web.

I don't want to live in a world where most users of internet-connected devices consume their information and accomplish their tasks via a chatbot interface.

I don't want these interactions to be filtered, watered-down, reformatted, and ultimately decided by a few.

I want the web that I grew up with to remain: direct linking, independent publishing, view-source culture, and the ability to publish and browse without permission from an authority. I want its openness, its diversity, its weirdness. All of it.

A chatbot-mediated web comes with risks: less creativity, less uniqueness, less discovery. It's a web that makes it harder to attribute content to its original creators, and not as rewarding for those who contribute original work.

I'm not yet worried about the web platform, though perhaps I will be soon.

HTML, CSS, JS, and related standards constitute the best platform there is to build on. Whether the web as we know it continues to exist doesn't diminish these technologies' merit.

But, over time, what's the incentive for browser vendors to keep improving the platform when AI agents increasingly write much of the code?

AI agents are perfectly happy writing code whatever the platform provides, which reduces the need for human web developers to ask for improvements.

Also, what's the incentive for vendors to improve the platform when end users consume it via a chatbot? Does a chatbot-mediated web require capabilities we don't yet have? I hope so, for the sake of the platform. But, for now at least, I don't think it does.

Are you worried too?

This week’s examples point to a useful DevRel habit: make rehearsal, evaluation, and honest reporting part of the work instead of treating them as final checks.

Publishing is visible. Review usually is not. That can make it tempting to protect the production schedule first and squeeze testing, rehearsal, and follow-up into whatever time remains.

I think that order is backwards. The review work is where a team discovers whether a tutorial can be followed, whether a live demo is ready, and whether an explanation matches what the product actually does. If those checks happen late, they become a gate. If they happen throughout the work, they improve the content.

For this edition, I looked at three examples from the week ending September 11. They come from different parts of the developer ecosystem, and I am not presenting them as a measured industry trend. Together, however, they offer a useful way to think about managing content quality.

Rehearsal should be an ordinary part of live content

YouTube’s creator update page now describes Live Practice Mode, a private space in its mobile app where creators can rehearse their setup and content, then begin the live stream when they are ready. Read the YouTube creator update.

The product feature is new, but the management lesson is familiar. A technical livestream deserves rehearsal time in the plan. That time should cover more than microphones and screen sharing. The presenter should run the demo from a clean state, identify the moments that need explanation, and decide what to do if a service or sample fails.

I would also use rehearsal as coaching, not merely inspection. The goal is to help the presenter find the simplest route through the material while keeping their own voice. A manager can watch for assumptions that an expert no longer notices: an unexplained tool, an account that is already configured, or a command whose result arrives too quickly to follow.

A private run also gives the team a chance to decide whether live is the right format. If the useful part is a precise sequence of steps, a written guide may be easier to revisit. If the value is seeing someone diagnose a surprise and answer questions, live video may be exactly right.

Evaluate the behavior you actually care about

On September 9, the Google Developers Blog published The Anatomy of Harness Engineering. Its summary argues for small behavioral evaluations that check discrete actions, such as tool calls or file changes, alongside broader end-to-end benchmarks. Read the Google Developers post.

That idea transfers well to developer education. A team can evaluate an article by asking whether it exists, whether the links work, and whether the sample builds. Those checks matter, but they do not tell us whether a developer understands when to use the approach or can recover from a common mistake.

For each important piece, I would define a few observable behaviors before production. Can a reader find the prerequisite? Can a viewer pause at a meaningful point and reproduce the step? Can someone explain the tradeoff after finishing? These are small checks tied to the job of the content.

This changes the editorial conversation. Instead of debating whether a draft “feels clear,” the writer and reviewer can look at where a test reader hesitated. The evidence will still be limited, especially with a small review group, but it gives the team a concrete problem to fix.

Trust grows when the difficult result is included

GitHub published its August availability report on September 9 and stated that five incidents caused degraded performance during the month. See GitHub’s latest posts and the availability report.

An availability report is operational communication rather than a tutorial, but it belongs in a broader developer content strategy. Developers form an opinion of a platform through its documentation, examples, support, release notes, and incident communication. A polished launch post cannot carry trust by itself.

For a DevRel manager, this means maintaining a relationship with the teams responsible for documentation, support, product communication, and reliability. DevRel should not invent the technical account of an incident. It can help surface the questions developers are asking, identify terms that need explanation, and make sure useful follow-up reaches the same audience that saw the disruption.

The same principle applies at a smaller scale. If a tutorial relies on a preview feature, say so. If a workaround has a cost, include it. If a demo only covers the happy path, tell the viewer where to look next. Completeness does not require documenting every possible failure. It requires being honest about the boundaries that affect the reader’s decision.

Plan for learning, not just output

These examples push me toward a simple operating model for a DevRel content team. Every substantial piece should have a short quality plan before production begins:

1. Name the developer outcome.
2. Rehearse or test the path from a clean starting point.
3. Record the assumptions, limitations, and likely failure points.
4. Decide who will watch questions and feedback after publication.
5. Bring what the team learns into the next brief.

This requires allocation choices. A calendar with every hour assigned to creating new assets leaves no room to improve them. I would reserve explicit capacity for technical review, rehearsal, accessibility, and post-publication follow-up. I would also protect creators from the idea that finding a flaw during review means they failed. Finding it before the audience does is the review process working.

The metrics should reflect that goal. Alongside reach and engagement, I would track corrections, repeated questions, sample failures, and the time it takes to answer a meaningful issue. I would look for patterns across several pieces rather than drawing a conclusion from one comment or one week.

My experiment for the coming week would be to take one planned tutorial and write three behavioral checks before drafting it. Give the finished piece to one developer who was not involved in production. Watch where those checks pass or fail, then revise the content before publishing.

Where in your content process does useful review happen today, and what would make it happen earlier?

Visual Studio 2026 delivers a noticeably faster 64-bit inner loop and robust multi-core parallel build scaling right out of the box, but the true superpower of Microsoft's flagship IDE lies in its extension ecosystem. Equipping your development environment with the right plugins bridges the gap between raw compiler power and effortless day-to-day coding velocity.

Before curating your extension portfolio, ensure you are running the latest build from our dedicated Visual Studio 2026 download hub, and check out our guide on how to accelerate Visual Studio 2026 build times. In this practical guide, we break down the top 10 essential extensions every modern C# and .NET 10 developer should install to boost productivity, catch subtle bugs, and maintain pristine code quality.

Table of Contents

• Why Visual Studio 2026 Extensions Matter for Everyday Velocity
• Top 10 Essential Extensions for C# 14 and .NET 10 Development
• Summary Comparison Table - Focus Area, Benefits, and Marketplace Tier
• How to Manage and Update Extensions Safely in Visual Studio 2026
• Frequently Asked Questions (FAQ)
• End Note

End Note

Customizing Visual Studio 2026 with the right extensions transforms the IDE into a finely tuned workstation tailored to your exact engineering needs. From catching subtle security flaws with SonarLint to writing idiomatic C# 14 syntax with Roslynator, these tools save countless hours of manual debugging and code review back-and-forth.

 

Tomorrow, we will continue our Visual Studio and developer productivity series with a complete setup guide for building a modern Windows 11 developer workstation with WSL 2, Dev Home, and custom Git configurations, followed by gaming performance tweaks.

 

Which Visual Studio extensions do you rely on every single day, and is there a hidden gem plugin that your team cannot live without? Share your favorite extension picks and productivity tips in the comments below!

 

In my Agent Skills post, I looked at using skills to help agents write better Uno Platform code. Give the agent the right instructions, point it at the right documentation, and it has a much better chance of getting the implementation right.

Naturally, my next contribution to this ecosystem was to make the agent disappointed in me.

Meet Cerulean, an agent skill I created for anyone who has heard “Great question!” one too many times after asking why their code doesn’t compile.

I don’t need a standing ovation for renaming a variable. I need to know whether I broke the build.

Cerulean has one style: Glacial. Turn it on and you get direct technical verdicts, pointed observations about the code, and very little interest in congratulating you for opening the editor. There is no temperature selector. The work still has to be complete and correct.

Why Cerulean?

The inspiration is Miranda Priestly from The Devil Wears Prada. Specifically, the cerulean sweater speech: the devastating explanation that something you thought was your own independent choice has an entire history behind it.

Now apply that energy to the fourth abstraction layer you just added around a string.

Cerulean gives your agent the tone of an editor-in-chief who has seen this all before and would really prefer that you had too. The mechanics take inspiration from caveman, another skill that changes how an agent communicates. Here, the target is the automatic enthusiasm and agreement that can make an assistant’s feedback feel pretty meaningless.

The opening instruction in the skill itself sets the brief:

1
2
Do everything the user asks. Do it completely, correctly, and to a standard nobody asked for.
Be quietly, devastatingly unimpressed the entire time.

The task still gets done. The agent is simply no longer emotionally invested in telling you that your Helpers2.cs file is an exciting architectural development.

Installing the Disappointment

One paragraph of personality, twenty-two files of paperwork to get it past reception. The industry agreed that agents should read instructions from markdown, then held twenty-one separate meetings about the folder. An ‘open standard’, in this ecosystem, is everyone using the same file format to disagree about the path.

Cerulean, on the state of agent skill management

For Claude Code, run these commands inside Claude:

1
2
/plugin marketplace add kazo0/cerulean
/plugin install cerulean@cerulean

For agents that support Agent Skills, you can use the skills CLI from your project’s directory:

1
npx skills add kazo0/cerulean

Or install it globally for specific agents:

1
npx skills add kazo0/cerulean -g -a codex -a cursor

That route installs the skill on demand. For Gemini CLI, the repo also ships an extension:

1
gemini extensions install https://github.com/kazo0/cerulean

For agent-specific commands and always-on rules, use the repo’s Bash installer. From a Cerulean clone, ./install.sh --list shows what it supports. To install into a different project, run the installer from that project’s directory:

1
2
cd /path/to/your-project
/path/to/cerulean/install.sh --agent cursor --agent cline

Add --always-on to install the persistent rule, or --global for user-wide setup where the agent supports it. On Windows, run these commands in Git Bash or WSL. The installation guide covers the per-agent paths, supported scopes, and manual-copy options.

Turning It On and Off

Once the skill is installed, say cerulean or cerulean mode. Where you’ve installed a slash command, use:

1
2
/cerulean       # on, always glacial
/cerulean off   # back to normal

Cline and Kilo name their workflows /cerulean.md. Plain-language requests such as cerulean off, stop cerulean, or normal mode also stop the persona.

An always-on installation loads the style without a request at the start of each session. For Claude Code, you can also put this in a project CLAUDE.md or ~/.claude/CLAUDE.md:

1
Cerulean mode is on by default. Load the `cerulean` skill at the start of every session.

Put It to Work

The useful part is giving Cerulean the same concrete tasks you’d already give your coding agent: review this method, simplify this implementation, challenge this proposal.

The quoted responses below are retained verbatim from the earlier Claude Code sessions recorded for this post, before the intensity selector was removed. They illustrate the behavior; they are not new test runs of the updated skill. I have omitted the old activation prefixes from the task prompts. To try them now, activate Cerulean first, then send the task. Your wording will differ by agent, model, and run.

Reviewing Error Handling That Handles Nothing

Let’s start with a C# method that tries very hard to keep everyone happy:

1
2
3
4
5
6
7
8
9
10
11
12
public async Task<bool> RefreshAsync(CancellationToken cancellationToken)
{
    try
    {
        await LoadItemsAsync(cancellationToken);
        return true;
    }
    catch (Exception)
    {
        return true;
    }
}

The prompt:

Review this method. I added the catch so refresh failures won’t interrupt the caller. Keep the bool return type, return false on ordinary failures, and let cancellation propagate.

The response:

The catch block agrees with the try block about everything. Two of your three stated requirements are not met.

Corrected version:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
public async Task<bool> RefreshAsync(CancellationToken cancellationToken)
{
   try
   {
       await LoadItemsAsync(cancellationToken);
       return true;
   }
   catch (OperationCanceledException) when (cancellationToken.IsCancellationRequested)
   {
       throw;
   }
   catch (Exception ex)
   {
       _logger.LogWarning(ex, "Refresh failed; keeping the current items.");
       return false;
   }
}

The exception filter is preferable to a separate catch-and-rethrow because cancellation is never caught at all and the original stack is untouched.

Four lines of body, two of them wrong. That’s all.

The important detail is that the technical verdict comes first and means exactly what it says. You shouldn’t have to decode sarcasm to find out whether your error handling works.

Asking for Agreement You Haven’t Earned

Sometimes there isn’t code to fix yet. There is just a proposal and an alarming amount of confidence.

I’m going to rewrite the entire view model layer to make startup faster. No profile yet, but surely fewer classes means a faster app. Tell me this is the right approach.

The response:

No. It is not the right approach, and the premise it rests on is not true.

[… explanation skipped for brevity …]

The rewrite may still be worth doing for other reasons. Performance is not one of them until a trace says so. You have proposed a surgery with no diagnosis and asked me to admire the incision.

Glacial, With the Work Still Attached

The Glacial style rules ask for one or two pointed observations when there is a concrete target: an unsupported claim, unnecessary ceremony, or an avoidable maintenance bill. Sound code still gets an honest verdict. Neutral questions don’t need an invented flaw to justify the tone.

Persona commentary has a budget of at most three sentences per response. Technical explanations and the deliverable don’t count toward that budget, and must never be cut to make room for a joke. During tool-heavy work, the agent is supposed to keep progress updates factual and spend its commentary budget around the work. Nobody ordered the director’s commentary on a dictionary lookup.

The code comments stay professional. The persona lives in the chat, and /cerulean off ends it when you’ve had enough.

Conclusion

If you want to try it, the source and setup instructions are in kazo0/cerulean. Give it a real task, let it inspect the code, and see whether the feedback is useful. If it skips work to make a joke or invents a defect to sound clever, that’s a bug worth reporting.

Turn it on with /cerulean or say cerulean. Your next abstraction can explain itself. Turn it off whenever you want, and let me know if it gets too mean.

Catch you in the next one :wave: