diff --git a/releases/v0.13.0.md b/releases/v0.13.0.md
new file mode 100644
index 0000000..035e9f0
--- /dev/null
+++ b/releases/v0.13.0.md
@@ -0,0 +1,88 @@
+# Release Notes for v0.13.0
+
+Release Date: March 24th, 2025
+
+This release is based on [3.15.0](https://github.com/kata-containers/kata-containers/releases/tag/3.13.0) of Kata Containers
+and [v0.11.0](https://github.com/confidential-containers/enclave-cc/releases/tag/v0.11.0) of enclave-cc.
+
+Kata and the CoCo components share an MSRV of 1.80.0.
+
+Please see the [quickstart guide](https://confidentialcontainers.org/docs/getting-started/) or [project documentation](https://confidentialcontainers.org/docs) for more information.
+
+## What's new
+
+* AMD SEV(-ES) support has been deprecated and will be removed in the next release.
+* AMD SEV-SNP deployments are compatible with upstream (6.11+) host kernels.
+* Trustee uses ECDH keys by default for KBS protocol.
+* Reliabilty of image pulling has been improved (bug fixes below).
+* The repository field of the resource URI is no longer optional.
+* TDX Attestation uses configfs-tsm based reports only and disables the libtdx-attest fallback.
+* Trustee documentation added to project website.
+* Trustee attestation policy improved for TDX.
+* Blocking logs endpoint with policy can no longer cause deadlocks.
+
+## Bug Fixes
+* Fixed an issue where pulling images with many layers failed due to exceeding the 4KB length limit on mount parameters.
+* Fixed an issue where image whiteout files appeared in the unpacked container filesystem due to the guest's tmpfs not supporting xattr.
+* Fixed an issue where the RCAR handshake in the KBS protocol did not treat JWE protected header as AEAD.
+
+## Hardware Support
+
+Attestation is supported and tested on three platforms: Intel TDX, AMD SEV-SNP, and IBM SE.
+Not all features have been tested on every platform, but those based on attestation
+are expected to work on the platforms above.
+
+Make sure your host platform is compatible with the hypervisor and guest kernel
+provisioned by CoCo.
+
+This release has been tested on the following stacks:
+
+### AMD SEV-SNP
+
+* Processor: AMD EPYC 7413
+* Kernel: 6.12.0-snp-host-adc218676 (upstream 6.11+) 
+* OS: Ubuntu 22.04.4 LTS
+* k8s: v1.30.1 (Kubeadm)
+* Kustomize: v4.5.4
+
+### Intel TDX
+
+* Kernel: [6.8.0-1004-intel](https://git.launchpad.net/~kobuk-team/ubuntu/+source/linux-intel/tree/?h=noble-main-next)
+* OS: Ubuntu 24.04 LTS
+* k8s: v1.30.2 (Kubeadm)
+* Kustomize: v5.0.4-0.20230601165947-6ce0bf390ce3
+
+### Secure Execution on IBM zSystems (s390x) running LinuxONE
+
+* Hardware: IBM Z16 LPAR
+* Kernel: 5.15.0-113-generic
+* OS: Ubuntu 22.04.1 LTS
+* k8s: v1.28.4 (Kubeadm)
+* Kustomize: v5.3.0
+
+## Limitations
+
+The following are limitations and known issues with this release.
+
+* Credentials for authenticated registries are exposed to the host.
+* Not all features are tested on all platforms.
+* Nydus snapshotter support is not mature.
+  * Nydus snapshotter sometimes fails to pull an image.
+  * Host pulling with Nydus snapshotter is not yet enabled.
+  * Nydus snapshotter is not supported with enclave-cc.
+* Pulling container images inside guest may have negative performance implications including greater resource usage and slower startup.
+* `crio` support is still evolving.
+* Platform support is rapidly changing
+* SELinux is not supported on the host and must be set to permissive if in use.
+* Complete integration with Kubernetes is still in progress.
+  * Existing APIs do not fully support the CoCo security and threat model. [More info](https://github.com/confidential-containers/confidential-containers/issues/53)
+  * Some commands accessing confidential data, such as `kubectl exec`, may either fail to work, or incorrectly expose information to the host
+* The CoCo community aspires to adopting open source security best practices, but not all practices are adopted yet.
+* Container metadata such as environment variables are not measured.
+* The Kata Agent allows the host to call several dangerous endpoints
+    * Kata Agent does not validate mount requests. A malicious host might be able to mount a shared filesystem into the PodVM.
+    * Policy can be used to block endpoints, but it is not yet tied to the hardware evidence.
+
+## CVE Fixes
+
+None