Trusted Platforms must solve known problems that people want solved, or enable people to do desirable things that they can't do with ordinary platforms. Trusted Platforms were therefore designed to support three main phases of functionality, each requiring more support investment than the previous stage:
A Trusted Platform must at least provide an application programming interface (API) to its trusted functions. This alone will justify the purchase of a Trusted Platform by sophisticated customers, because it allows a knowledgeable user to develop his or her own trusted applications, and permits any application that uses standard crypto APIs to use a Trusted Platform's hardware-enforced digital signature and confidentiality functions.
If the platform has an OS that measures the loading of executables, the platform's signing and confidential storage trusted functions can be augmented to take into account the software state of the OS and applications. This provides a measure of defense against hacker scripts and the like, and against inadvertent exposure of sensitive data. Of course, applications may have to be altered to take explicit advantage of this extra protection. Little or no infrastructure change is required.
If the platform is provided with an OS or application that can also interpret platform identities and the trust state of a platform, electronic services can make use of the trusted state of a platform and take appropriate action. This requires some network infrastructure with Certificate Authorities to attest to platform identities.