When the MDM is running in a cloud, it may not have a start-up or power on sequence like a traditional server-based deployment would. So it isn't clear how this would be met. For example, the TOE may rely on the cloud platform to ensure proper correctness when being loaded. This is hinted at in the app note, but in a cloud environment this is pretty normal, that the environment ensures that the loaded application is the "right" one and that it is loaded correctly.
For example, if a trusted version of the software is deployed to the cloud infrastructure, the infrastructure will likely ensure that any instance of the software that is loaded matches that trusted version. Once running, the instance doesn't really stop and start, so self tests at start-up aren't very meaningful, since the deployment of the service likely means that it never really stops after that, even when upgraded, it would be upgraded in stages across all the servers, maintaining both instances until all had been upgraded fully.
This is critical for scalability, that a trusted version can be loaded and know that it will be the same anywhere in the cloud and respond accordingly. In this case, it is more like a Trusted Deployment requirement that ensures that the component(s) are loaded from something that the system can trust.
When the MDM is running in a cloud, it may not have a start-up or power on sequence like a traditional server-based deployment would. So it isn't clear how this would be met. For example, the TOE may rely on the cloud platform to ensure proper correctness when being loaded. This is hinted at in the app note, but in a cloud environment this is pretty normal, that the environment ensures that the loaded application is the "right" one and that it is loaded correctly.
For example, if a trusted version of the software is deployed to the cloud infrastructure, the infrastructure will likely ensure that any instance of the software that is loaded matches that trusted version. Once running, the instance doesn't really stop and start, so self tests at start-up aren't very meaningful, since the deployment of the service likely means that it never really stops after that, even when upgraded, it would be upgraded in stages across all the servers, maintaining both instances until all had been upgraded fully.
This is critical for scalability, that a trusted version can be loaded and know that it will be the same anywhere in the cloud and respond accordingly. In this case, it is more like a Trusted Deployment requirement that ensures that the component(s) are loaded from something that the system can trust.