diff --git a/tests/scripts/components.sh b/tests/scripts/components.sh
deleted file mode 100644
index f0f9fe14d0..0000000000
--- a/tests/scripts/components.sh
+++ /dev/null
@@ -1,63 +0,0 @@
-# components.sh
-#
-# Copyright The Mbed TLS Contributors
-# SPDX-License-Identifier: Apache-2.0 OR GPL-2.0-or-later
-
-# This file contains the test components that are executed by all.sh
-
-# The functions below are named as follows:
-#  * component_XXX: independent components. They can be run in any order.
-#      * component_check_XXX: quick tests that aren't worth parallelizing.
-#      * component_build_XXX: build things but don't run them.
-#      * component_test_XXX: build and test.
-#      * component_release_XXX: tests that the CI should skip during PR testing.
-#  * support_XXX: if support_XXX exists and returns false then
-#    component_XXX is not run by default.
-
-# Each component must start by invoking `msg` with a short informative message.
-#
-# Warning: due to the way bash detects errors, the failure of a command
-# inside 'if' or '!' is not detected. Use the 'not' function instead of '!'.
-#
-# Each component is executed in a separate shell process. The component
-# fails if any command in it returns a non-zero status.
-#
-# The framework in all.sh performs some cleanup tasks after each component.
-# This means that components can assume that the working directory is in a
-# cleaned-up state, and don't need to perform the cleanup themselves.
-# * Run `make clean`.
-# * Restore `include/mbedtls/mbedtls_config.h` from a backup made before running
-#   the component.
-# * Check out `Makefile`, `library/Makefile`, `programs/Makefile`,
-#   `tests/Makefile` and `programs/fuzz/Makefile` from git.
-#   This cleans up after an in-tree use of CMake.
-#
-# The tests are roughly in order from fastest to slowest. This doesn't
-# have to be exact, but in general you should add slower tests towards
-# the end and fast checks near the beginning.
-
-
-################################################################
-#### Build and test many configurations and targets
-################################################################
-
-################################################################
-#### Basic checks
-################################################################
-
-#
-# Test Suites to be executed
-#
-# The test ordering tries to optimize for the following criteria:
-# 1. Catch possible problems early, by running first tests that run quickly
-#    and/or are more likely to fail than others (eg I use Clang most of the
-#    time, so start with a GCC build).
-# 2. Minimize total running time, by avoiding useless rebuilds
-#
-# Indicative running times are given for reference.
-
-################################################################
-#### Build and test many configurations and targets
-################################################################
-
-