diff --git a/3rdparty/everest/CMakeLists.txt b/3rdparty/everest/CMakeLists.txt
index eefc151..e0e5ade 100644
--- a/3rdparty/everest/CMakeLists.txt
+++ b/3rdparty/everest/CMakeLists.txt
@@ -18,11 +18,11 @@
 # everest is not directly linked against any mbedtls targets
 # so does not inherit the compile definitions.
 if(MBEDTLS_CONFIG_FILE)
-    target_compile_definitions(everest
+    target_compile_definitions(${everest_target}
         PUBLIC MBEDTLS_CONFIG_FILE="${MBEDTLS_CONFIG_FILE}")
 endif()
 if(MBEDTLS_USER_CONFIG_FILE)
-    target_compile_definitions(everest
+    target_compile_definitions(${everest_target}
         PUBLIC MBEDTLS_USER_CONFIG_FILE="${MBEDTLS_USER_CONFIG_FILE}")
 endif()
 
diff --git a/3rdparty/p256-m/CMakeLists.txt b/3rdparty/p256-m/CMakeLists.txt
index 41be3c4..2ef0d48 100644
--- a/3rdparty/p256-m/CMakeLists.txt
+++ b/3rdparty/p256-m/CMakeLists.txt
@@ -16,11 +16,11 @@
 # p256m is not directly linked against any mbedtls targets
 # so does not inherit the compile definitions.
 if(MBEDTLS_CONFIG_FILE)
-    target_compile_definitions(p256m
+    target_compile_definitions(${p256m_target}
         PUBLIC MBEDTLS_CONFIG_FILE="${MBEDTLS_CONFIG_FILE}")
 endif()
 if(MBEDTLS_USER_CONFIG_FILE)
-    target_compile_definitions(p256m
+    target_compile_definitions(${p256m_target}
         PUBLIC MBEDTLS_USER_CONFIG_FILE="${MBEDTLS_USER_CONFIG_FILE}")
 endif()
 
diff --git a/ChangeLog.d/fix-3rdparty-target-prefix.txt b/ChangeLog.d/fix-3rdparty-target-prefix.txt
new file mode 100644
index 0000000..db8ed07
--- /dev/null
+++ b/ChangeLog.d/fix-3rdparty-target-prefix.txt
@@ -0,0 +1,3 @@
+Bugfix
+   * Fix accidental omission of MBEDTLS_TARGET_PREFIX in 3rdparty modules
+     in CMake.
diff --git a/docs/architecture/psa-thread-safety.md b/docs/architecture/psa-thread-safety.md
index b0ca808..06bdcc0 100644
--- a/docs/architecture/psa-thread-safety.md
+++ b/docs/architecture/psa-thread-safety.md
@@ -67,16 +67,32 @@
 
 We may want to go directly to a more sophisticated approach because when a system works with a global lock, it's typically hard to get rid of it to get more fine-grained concurrency.
 
+### Key destruction short-term requirements
+
+#### Summary of guarantees in the short term
+
+When `psa_destroy_key` returns:
+
+1. The key identifier doesn't exist. Rationale: this is a functional requirement for persistent keys: the caller can immediately create a new key with the same identifier.
+2. The resources from the key have been freed. Rationale: in a low-resource condition, this may be necessary for the caller to re-create a similar key, which should be possible.
+3. The call must not block indefinitely, and in particular cannot wait for an event that is triggered by application code such as calling an abort function. Rationale: this may not strictly be a functional requirement, but it is an expectation `psa_destroy_key` does not block forever due to another thread, which could potentially be another process on a multi-process system. In particular, it is only acceptable for `psa_destroy_key` to block, when waiting for another thread to complete a PSA Cryptography API call that it had already started.
+
+When `psa_destroy_key` is called on a key that is in use, guarantee 2. might be violated. (This is consistent with the requirement [“Correctness out of the box”](#correctness-out-of-the-box), as destroying a key while it's in use is undefined behavior.)
+
 ### Key destruction long-term requirements
 
-As noted above in [“Correctness out of the box”](#correctness-out-of-the-box), when a key is destroyed, it's ok if `psa_destroy_key` allows copies of the key to live until ongoing operations using the key return. In the long term, it would be good to guarantee that `psa_destroy_key` wipes all copies of the key material.
+The [PSA Crypto API specification](https://armmbed.github.io/mbed-crypto/html/api/keys/management.html#key-destruction) mandates that implementations make a best effort to ensure that the key material cannot be recovered. In the long term, it would be good to guarantee that `psa_destroy_key` wipes all copies of the key material.
 
-#### Summary of guarantees when `psa_destroy_key` returns
+#### Summary of guarantees in the long term
 
-* The key identifier doesn't exist. Rationale: this is a functional requirement for persistent keys: the caller can immediately create a new key with the same identifier.
-* The resources from the key have been freed. Rationale: in a low-resource condition, this may be necessary for the caller to re-create a similar key, which should be possible.
-* The call must not block indefinitely, and in particular cannot wait for an event that is triggered by application code such as calling an abort function. Rationale: this may not strictly be a functional requirement, but it is an expectation `psa_destroy_key` does not block forever due to another thread, which could potentially be another process on a multi-process system.
-* In the long term, no copy of the key material exists. Rationale: this is a security requirement. We do not have this requirement yet, but we need to document this as a security weakness, and we would like to become compliant.
+When `psa_destroy_key` returns:
+
+1. The key identifier doesn't exist. Rationale: this is a functional requirement for persistent keys: the caller can immediately create a new key with the same identifier.
+2. The resources from the key have been freed. Rationale: in a low-resource condition, this may be necessary for the caller to re-create a similar key, which should be possible.
+3. The call must not block indefinitely, and in particular cannot wait for an event that is triggered by application code such as calling an abort function. Rationale: this may not strictly be a functional requirement, but it is an expectation `psa_destroy_key` does not block forever due to another thread, which could potentially be another process on a multi-process system. In particular, it is only acceptable for `psa_destroy_key` to block, when waiting for another thread to complete a PSA Cryptography API call that it had already started.
+4. No copy of the key material exists. Rationale: this is a security requirement. We do not have this requirement yet, but we need to document this as a security weakness, and we would like to satisfy this security requirement in the future.
+
+As opposed to the short term requirements, all the above guarantees hold even if `psa_destroy_key` is called on a key that is in use.
 
 ## Resources to protect
 
diff --git a/include/mbedtls/config_adjust_legacy_crypto.h b/include/mbedtls/config_adjust_legacy_crypto.h
index 6ec59f1..495cd5a 100644
--- a/include/mbedtls/config_adjust_legacy_crypto.h
+++ b/include/mbedtls/config_adjust_legacy_crypto.h
@@ -79,7 +79,7 @@
 #define MBEDTLS_ECP_LIGHT
 #endif
 
-/* MBEDTLS_PK_PARSE_EC_COMPRESSED is introduced in MbedTLS version 3.5, while
+/* MBEDTLS_PK_PARSE_EC_COMPRESSED is introduced in Mbed TLS version 3.5, while
  * in previous version compressed points were automatically supported as long
  * as PK_PARSE_C and ECP_C were enabled. As a consequence, for backward
  * compatibility, we auto-enable PK_PARSE_EC_COMPRESSED when these conditions
diff --git a/library/pkcs12.c b/library/pkcs12.c
index dd3a240..4db2a4b 100644
--- a/library/pkcs12.c
+++ b/library/pkcs12.c
@@ -169,6 +169,7 @@
     unsigned char iv[16];
     const mbedtls_cipher_info_t *cipher_info;
     mbedtls_cipher_context_t cipher_ctx;
+    size_t iv_len = 0;
     size_t finish_olen = 0;
     unsigned int padlen = 0;
 
@@ -196,9 +197,10 @@
         }
     }
 
+    iv_len = mbedtls_cipher_info_get_iv_size(cipher_info);
     if ((ret = pkcs12_pbe_derive_key_iv(pbe_params, md_type, pwd, pwdlen,
                                         key, keylen,
-                                        iv, mbedtls_cipher_info_get_iv_size(cipher_info))) != 0) {
+                                        iv, iv_len)) != 0) {
         return ret;
     }
 
@@ -208,9 +210,8 @@
         goto exit;
     }
 
-    if ((ret =
-             mbedtls_cipher_setkey(&cipher_ctx, key, 8 * keylen,
-                                   (mbedtls_operation_t) mode)) != 0) {
+    if ((ret = mbedtls_cipher_setkey(&cipher_ctx, key, 8 * keylen,
+                                     (mbedtls_operation_t) mode)) != 0) {
         goto exit;
     }
 
@@ -233,22 +234,8 @@
     }
 #endif /* MBEDTLS_CIPHER_MODE_WITH_PADDING */
 
-    if ((ret =
-             mbedtls_cipher_set_iv(&cipher_ctx, iv,
-                                   mbedtls_cipher_info_get_iv_size(cipher_info))) != 0) {
-        goto exit;
-    }
-
-    if ((ret = mbedtls_cipher_reset(&cipher_ctx)) != 0) {
-        goto exit;
-    }
-
-    if ((ret = mbedtls_cipher_update(&cipher_ctx, data, len,
-                                     output, output_len)) != 0) {
-        goto exit;
-    }
-
-    if ((ret = mbedtls_cipher_finish(&cipher_ctx, output + (*output_len), &finish_olen)) != 0) {
+    ret = mbedtls_cipher_crypt(&cipher_ctx, iv, iv_len, data, len, output, &finish_olen);
+    if (ret == MBEDTLS_ERR_CIPHER_INVALID_PADDING) {
         ret = MBEDTLS_ERR_PKCS12_PASSWORD_MISMATCH;
     }
 
diff --git a/library/psa_crypto_pake.c b/library/psa_crypto_pake.c
index 7a904d9..db00cbd 100644
--- a/library/psa_crypto_pake.c
+++ b/library/psa_crypto_pake.c
@@ -304,10 +304,10 @@
 
 #if defined(MBEDTLS_PSA_BUILTIN_ALG_JPAKE)
     /*
-     * The PSA CRYPTO PAKE and MbedTLS JPAKE API have a different
+     * The PSA CRYPTO PAKE and Mbed TLS JPAKE API have a different
      * handling of output sequencing.
      *
-     * The MbedTLS JPAKE API outputs the whole X1+X2 and X2S steps data
+     * The Mbed TLS JPAKE API outputs the whole X1+X2 and X2S steps data
      * at once, on the other side the PSA CRYPTO PAKE api requires
      * the KEY_SHARE/ZP_PUBLIC/ZK_PROOF parts of X1, X2 & X2S to be
      * retrieved in sequence.
@@ -423,17 +423,17 @@
 
 #if defined(MBEDTLS_PSA_BUILTIN_ALG_JPAKE)
     /*
-     * The PSA CRYPTO PAKE and MbedTLS JPAKE API have a different
+     * The PSA CRYPTO PAKE and Mbed TLS JPAKE API have a different
      * handling of input sequencing.
      *
-     * The MbedTLS JPAKE API takes the whole X1+X2 or X4S steps data
+     * The Mbed TLS JPAKE API takes the whole X1+X2 or X4S steps data
      * at once as input, on the other side the PSA CRYPTO PAKE api requires
      * the KEY_SHARE/ZP_PUBLIC/ZK_PROOF parts of X1, X2 & X4S to be
      * given in sequence.
      *
      * In order to achieve API compatibility, each X1+X2 or X4S step data
      * is stored sequentially in an intermediate buffer and given to the
-     * MbedTLS JPAKE API on the last step.
+     * Mbed TLS JPAKE API on the last step.
      *
      * This causes any input error to be only detected on the last step.
      */
diff --git a/programs/ssl/ssl_context_info.c b/programs/ssl/ssl_context_info.c
index 855b091..9744c58 100644
--- a/programs/ssl/ssl_context_info.c
+++ b/programs/ssl/ssl_context_info.c
@@ -1,5 +1,5 @@
 /*
- *  MbedTLS SSL context deserializer from base64 code
+ *  Mbed TLS SSL context deserializer from base64 code
  *
  *  Copyright The Mbed TLS Contributors
  *  SPDX-License-Identifier: Apache-2.0
diff --git a/scripts/code_size_compare.py b/scripts/code_size_compare.py
index 53d859e..e764e9d 100755
--- a/scripts/code_size_compare.py
+++ b/scripts/code_size_compare.py
@@ -901,7 +901,7 @@
         '-c', '--config', type=str, default=SupportedConfig.DEFAULT.value,
         choices=list(map(lambda s: s.value, SupportedConfig)),
         help='Specify configuration type for code size comparison. '
-             '(Default is the current MbedTLS configuration.)')
+             '(Default is the current Mbed TLS configuration.)')
     group_optional.add_argument(
         '--markdown', action='store_true', dest='markdown',
         help='Show comparision of code size in a markdown table. '
diff --git a/tests/scripts/all.sh b/tests/scripts/all.sh
index 9e1d84f..7e6c95c 100755
--- a/tests/scripts/all.sh
+++ b/tests/scripts/all.sh
@@ -1164,21 +1164,6 @@
     tests/context-info.sh
 }
 
-component_test_full_cmake_gcc_asan_new_bignum_test_hooks () {
-    msg "build: full config, cmake, gcc, ASan"
-    scripts/config.py full
-    scripts/config.py set MBEDTLS_TEST_HOOKS
-    scripts/config.py set MBEDTLS_ECP_WITH_MPI_UINT
-    CC=gcc cmake -D CMAKE_BUILD_TYPE:String=Asan .
-    make
-
-    msg "test: main suites (inc. selftests) (full config, ASan build)"
-    make test
-
-    msg "test: selftest (ASan build)" # ~ 10s
-    programs/test/selftest
-}
-
 component_test_psa_crypto_key_id_encodes_owner () {
     msg "build: full config + PSA_CRYPTO_KEY_ID_ENCODES_OWNER, cmake, gcc, ASan"
     scripts/config.py full
diff --git a/tests/scripts/audit-validity-dates.py b/tests/scripts/audit-validity-dates.py
index 623fd23..5128dc7 100755
--- a/tests/scripts/audit-validity-dates.py
+++ b/tests/scripts/audit-validity-dates.py
@@ -276,7 +276,7 @@
 
     @staticmethod
     def find_test_dir():
-        """Get the relative path for the MbedTLS test directory."""
+        """Get the relative path for the Mbed TLS test directory."""
         return os.path.relpath(build_tree.guess_mbedtls_root() + '/tests')
 
 
diff --git a/tests/scripts/check_names.py b/tests/scripts/check_names.py
index f812929..86a7c09 100755
--- a/tests/scripts/check_names.py
+++ b/tests/scripts/check_names.py
@@ -941,7 +941,7 @@
             "This script confirms that the naming of all symbols and identifiers "
             "in Mbed TLS are consistent with the house style and are also "
             "self-consistent.\n\n"
-            "Expected to be run from the MbedTLS root directory.")
+            "Expected to be run from the Mbed TLS root directory.")
     )
     parser.add_argument(
         "-v", "--verbose",
diff --git a/tests/scripts/test_psa_compliance.py b/tests/scripts/test_psa_compliance.py
index 3590436..34b4494 100755
--- a/tests/scripts/test_psa_compliance.py
+++ b/tests/scripts/test_psa_compliance.py
@@ -46,7 +46,7 @@
 }
 
 # We currently use a fork of ARM-software/psa-arch-tests, with a couple of downstream patches
-# that allow it to build with MbedTLS 3, and fixes a couple of issues in the compliance test suite.
+# that allow it to build with Mbed TLS 3, and fixes a couple of issues in the compliance test suite.
 # These fixes allow the tests numbered 216, 248 and 249 to complete successfully.
 #
 # Once all the fixes are upstreamed, this fork should be replaced with an upstream commit/tag.
diff --git a/tests/suites/test_suite_pkcs12.data b/tests/suites/test_suite_pkcs12.data
index c4e4d77..64c9991 100644
--- a/tests/suites/test_suite_pkcs12.data
+++ b/tests/suites/test_suite_pkcs12.data
@@ -1,4 +1,4 @@
-PKCS#12 derive key : MD5: Zero length password and hash
+PKCS#12 derive key: MD5: Zero length password and hash
 depends_on:MBEDTLS_MD_CAN_MD5
 pkcs12_derive_key:MBEDTLS_MD_MD5:48:"":USE_GIVEN_INPUT:"":USE_GIVEN_INPUT:3:"6afdcbd5ebf943272134f1c3de2dc11b6afdcbd5ebf943272134f1c3de2dc11b6afdcbd5ebf943272134f1c3de2dc11b":0