For MDMs that are provided as hosted services, the admin doesn't necessarily have any choice in the version of the MDM that is in use. It may (or may not) be readily possible to know the version of the software being hosted in the cloud.
As updates though are likely installed through automated means without the interaction of the admin it isn't clear how 1.2 would be met given that they wouldn't have the ability to perform the update themselves, it would be handled by the vendor automatically.
Lastly, for 1.3, depending on the type of code, it may not be signed as a single bundle like an installation application. Some deployment methods instead of relying on signatures rely on full supply chain (the entire process from source code to publication) to be explicitly tracked and traced in prescribed manners. Since the code isn't intended for wider installation (i.e. sending it out so it could be installed locally or on a 3P cloud instance), this provides equivalent guarantees (or better), but it not something that would be readily exposed to the admin running the MDM since this is all handled as part of the service. This is based on, or similar to SLSA (https://slsa.dev/) within the vendor's infrastructure.
For MDMs that are provided as hosted services, the admin doesn't necessarily have any choice in the version of the MDM that is in use. It may (or may not) be readily possible to know the version of the software being hosted in the cloud.
As updates though are likely installed through automated means without the interaction of the admin it isn't clear how 1.2 would be met given that they wouldn't have the ability to perform the update themselves, it would be handled by the vendor automatically.
Lastly, for 1.3, depending on the type of code, it may not be signed as a single bundle like an installation application. Some deployment methods instead of relying on signatures rely on full supply chain (the entire process from source code to publication) to be explicitly tracked and traced in prescribed manners. Since the code isn't intended for wider installation (i.e. sending it out so it could be installed locally or on a 3P cloud instance), this provides equivalent guarantees (or better), but it not something that would be readily exposed to the admin running the MDM since this is all handled as part of the service. This is based on, or similar to SLSA (https://slsa.dev/) within the vendor's infrastructure.