diff --git a/docs/_posts/2026-08-25-pqc-tuf.md b/docs/_posts/2026-08-25-pqc-tuf.md
new file mode 100644
index 0000000000..427ba85479
--- /dev/null
+++ b/docs/_posts/2026-08-25-pqc-tuf.md
@@ -0,0 +1,56 @@
+---
+title: Post-Quantum TUF
+author: Jussi Kukkonen
+---
+
+TUF is a tricky technology to upgrade: cryptographic infrastructure, a heterogeneous
+client ecosystem and the ability to accidentally "brick" applications and devices
+mean that we prefer to move carefully and avoid breaking things.
+
+In the context of quantum computing, waiting until cryptographically relevant
+quantum computers appear may not be an option: Cryptographic signatures do not suffer
+from the _"store now, decrypt later"_ problem but our infrastructure upgrade schedules
+mean the work needs to be done early to avoid rushing it when quantum computers are a
+problem. See [Quantum frontiers may be closer than they appear](https://blog.google/innovation-and-ai/technology/safety-security/cryptography-migration-timeline/).
+
+
+## Standardization
+
+ML-DSA was chosen as the first PQC signature in the TUF ecosystem: it is a stateless,
+fairly efficient algorithm designed to replace quantum-vulnerable signing schemes like
+RSA and ECDSA.
+
+There are two TUF-specific issues to solve when any signing schemes are added:
+* **key and signature size**: TUF metadata size is largely dependent on these.
+* **Compatibility with externally managed keys**: TUF is often integrated with cloud
+  KMSs and hardware tokens like YubiKeys. Signing schemes that lack a pre-hashing
+  mechanism are problematic on these systems since the payload size limits become an
+  issue. 
+
+[TUF Augmentation Proposal (TAP) 21](https://github.com/theupdateframework/taps/blob/master/tap21.md)
+introduces the ML-DSA key type for TUF metadata and goes into detail about the issues.
+Most notably it defines an _application-level pre-hashing scheme_ to ensure compatibility
+with externally managed keys. While the "domain separator" used is TUF specific, the
+pre-hashing scheme should be usable in sibling projects like in-toto as well. The TAP
+also provides estimates of metadata sizes for repository maintainers to consider.
+
+## Implementation status
+
+Implementation work across the ecosystem is well underway:
+
+* [tuf-on-ci](https://github.com/theupdateframework/tuf-on-ci) (repository and signing
+  tool): Next release has ML-DSA support with Google Cloud KMS and Tillitis TKey hardware
+  tokens
+* [python-tuf](https://github.com/theupdateframework/python-tuf) (client library):
+  Support is available via securesystemslib 1.5 but
+  needs to be explicitly enabled by the application (while TAP is still a draft)
+* [sigstore-tuf](https://github.com/sigstore/sigstore-rust/tree/main/crates/sigstore-tuf)
+  (client library embedded in sigstore-rust): Next release has ML-DSA
+  support 
+* [go-tuf](https://github.com/theupdateframework/go-tuf) (client library): Integration
+  work is [ongoing](https://github.com/theupdateframework/go-tuf/pull/758)
+
+The TAP is likely to move to some accepted state soon as multiple implementations now
+exist: Now would be a good time for application developers and repository maintainers to
+try out ML-DSA in non-production environments and provide feedback on the TAP-21 and on
+the implementations.