Grandison i Sloman definiują zaufanie do infrastruktury jako gwarancję, że infrastruktura rzeczywiście działa zgodnie z reklamą. W przypadku sprzętu komputerowego zaproponowano użycie TPM w celu zapewnienia tej gwarancji. Szereg wstępnych artykułów na temat zarządzania zaufaniem w przetwarzaniu w chmurze wspomina o tej klasie zaufania. Li omawia ich model zaufania zwany wielodostępnym zaufanym modelem środowiska obliczeniowego (MTCEM), który obsługuje zaufanie infrastruktury. Autorzy zauważają, że w modelu przetwarzania w chmurze cele CSP i użytkownika chmury są sobie przeciwstawne. Podczas gdy użytkownik chmury chce najwyższej jakości usług przy najniższych kosztach, dostawca CSP chce uzyskać jak najwięcej pieniędzy ze swoich zasobów. Modele takie jak Wang zakładają zatem, że CSP jest przeciwnikiem użytkownika. Artykuł mówi dalej, że w przypadku tego modelu przeciwnika nie jest rozsądne pozwalanie CSP na obsługę wszystkich zabezpieczeń. MTCEM oddziela i dzieli obowiązki związane z bezpieczeństwem między użytkowników chmury i dostawców usług. Wymaga i wyznacza granice wspólnej odpowiedzialności za bezpieczeństwo między CSP a użytkownikiem. Bezpieczeństwo, a tym samym zaufanie do MTCEM opiera się na atestacji platformy i zaufaniu przechodnim zapewnianym przez TPM. MTCEM jest jednak przeznaczony głównie dla infrastruktury jako usługi (IaaS), gdzie odpowiedzialność za zaufaną infrastrukturę aż do VMM (pierwszy poziom) spoczywa na CSP, a od systemu gościa do aplikacji (na drugim poziomie) spoczywa na użytkowniku. Łańcuch zaufania rozpoczyna się od głównego źródła pomiaru zaufania (CRTM) modułu TPM, który jest zawsze zaufany. Każdy kolejny komponent systemu jest certyfikowany przez zaufany komponent, dopóki cały system nie zostanie poświadczony i zaufany. Użytkownik lub zaufana strona trzecia (TTP) w imieniu użytkownika może następnie ocenić łańcuch zaufania zapewniany przez dostawcę CSP i dalej go wykorzystywać w zakresie odpowiedzialności użytkownika za bezpieczeństwo. Mówię o bezpieczeństwie oprogramowania wdrażanego przez użytkowników w chmurze. Zaufanie w tym przypadku oznacza pewność, że oprogramowanie użytkownika nie zostało zmodyfikowane przez adwersarzy, którzy mogą próbować bezpośrednio uruchomić złośliwe oprogramowanie w chmurze lub umieścić złośliwy kod w legalnym oprogramowaniu. Klasyfikujemy to jako formę zaufania do infrastruktury, ponieważ założeniem jest, że użytkownik nie ufa, że infrastruktura chmury jest wystarczająco bezpieczna, aby chronić jego oprogramowanie. Architektura przedstawiona w artykule tworzy zaufane środowisko pracy dla oprogramowania użytkownika poprzez osadzenie w nim znaku wodnego i weryfikację znaku wodnego przed wykonaniem. Jednak architektura jest przeznaczona specjalnie dla oprogramowania napisanego w Javie i działającego na JVM. Użytkownik przed wdrożeniem oprogramowania osadza znak wodny w oprogramowaniu przy użyciu dowolnego odpowiedniego algorytmu znaku wodnego. Prototypowa implementacja ma do wyboru pulę 11 algorytmów. Program osadzający znak wodny akceptuje plik jar i znak wodny oraz wysyła plik jar ze znakiem wodnym. Maszyna JVM, na której będzie działać to oprogramowanie, również została zmodyfikowana i wzbogacona o moduł rozpoznawania znaków wodnych. Moduł rozpoznawania znaku wodnego jest specjalnie dostosowany do wyodrębniania powyższego znaku wodnego. Ta maszyna JVM jest następnie instalowana na maszynach, na których ma działać oprogramowanie użytkownika. Moduł rozpoznawania znaków wodnych w JVM uruchamia się losowo w czasie wykonywania w celu ciągłego sprawdzania poprawności oprogramowania użytkownika i zatrzymuje wykonywanie, jeśli weryfikacja nie powiedzie się. Implementacja algorytmu pokazuje, że istnieje tylko niewielki rozmiar i przeciążenie czasu wykonania