Here, provisioning includes all TPM setup that occurs less frequently than once per boot cycle. In a typical TPM lifetime, these actions may be performed only once.
This book divides the provisioning operations among three parties: the TPM manufacturer, the platform manufacturer (often referred to as the OEM), and the end user. Although this is a typical partition, the TPM doesn't enforce it, and enterprises may deviate from this pattern based on their trust model. For example, a platform in a large enterprise may further partition end-user provisioning between an actual user and an IT department administrator. A high security use case may replace a TPM vendor-supplied endorsement primary key or certificate with its own.
In TPM 1.2, certain provisioning steps could only be performed once. For example, although it had the concept of a revocable endorsement key that could be deleted and regenerated with a different value, this was optional and not implemented in commercial hardware TPMs.
In the TPM 2.0 architecture, there are no once-per-lifetime values. However, a platform specification may, for example, make TPM2_ChangeEPS optional, and a vendor may not implement it. In that case, an endorsement key created with a known template (see Chapter 15 for details) could not be permanently destroyed, although it could be flushed from the TPM. TPM 2.0 can also provision additional endorsement keys.
TPM Manufacturer Provisioning
The TPM manufacturer is uniquely qualified to certify that its hardware is authentic. Once the TPM part enters the supply chain, most purchasers don't have the expertise to distinguish a counterfeit from a genuine part.
The TPM generates a primary seed in the endorsement hierarchy when it's first powered on. The TPM manufacturer then uses TPM2_CreatePrimary one or more times to create endorsement primary keys—the ones at the root of the endorsement hierarchy.  This command returns the public key, which the manufacturer uses to create a certificate.
The certificate, typically in X.509 format, asserts that the public key belongs to a genuine vendor TPM. It typically includes manufacturer identification. There is no security-related reason for the vendor to store either the primary key or its certificate on the TPM. Practical concerns drive the decision.
The primary key is generated from the primary seed and a caller-supplied template. The template contains the key algorithm and size, and possibly other entropy. If the seed isn't changed, the same template will always generate the same key. Thus, the vendor need not ship the TPM with the key stored in persistent memory. The user can re-create it at any time. This avoids consuming valuable NV memory in cases where the TPM vendor generates many primary keys for different templates, or when the key is likely to be used infrequently.
Why does the TPM use seeds? TPM 1.2 generated the endorsement key directly, but there was one algorithm (RSA) and one key size (2,048 bits). TPM 2.0 can have many algorithms and key sizes. If the TPM 1.2 pattern was used, each key would have to be stored on the TPM, consuming valuable NV memory. The TPM 2.0 design requires only a single persistent seed. The derived keys can be generated (and then discarded) as needed.
The advantage of shipping the TPM with a primary endorsement key is performance.
Why have the user create the primary key when the vendor has already created it?
In practice, the TCG platform working groups are expected to specify one or more standard templates based on anticipated application needs. The TPM vendor will generate multiple keys but only provision one for a commonly used algorithm and size on the part before shipment.
A similar practical concern determines whether the TPM ships with certificates. Although it's true that a user can usually ask the TPM manufacturer for a certificate corresponding to their public key, it's certainly more convenient to read it from TPM NV storage. There may be use cases where the platform isn't connected to a public network, making certificate retrieval even more inconvenient. In practice, we expect the TPM vendor to provision a certificate corresponding to the one or more primary keys. The certificate likely resides in the TPM's NV storage.
There can be use cases where the user doesn't completely trust the TPM vendor processes. Other use cases require an end user such as a government agency to prevent any link in the supply chain from tracking which machines are used by that agency.
They want to remove any unique key that may aid in that tracking. This user can use TPM2_ChangeEPS to change the endorsement primary seed;  generate new, different primary keys;  and sign their own certificates. The user can also change the template to include a random number, which is unknown to the vendor, thus generating an endorsement primary key unknown to the vendor without invalidating existing primary key certificates.
In summary, the four differences from TPM 1.2 that contribute to these scenarios are as follows:
• Primary endorsement keys can be re-created at any time as long as the primary seed doesn't change and the template is known.
• Because primary endorsement keys can be re-created, they need not be stored long term in the TPM.
• Because TPM 2.0 supports multiple algorithms and added template entropy, there can be more than one primary endorsement key.
• If rolling the EPS is supported, endorsement keys can be deleted, and thus the certificates invalidated.
-  The manufacturer is permitted to create the endorsement primary seed externally and “squirt” it into the TPM in a vendor-specific process. This potentially saves manufacturing time, because the primary keys can also be calculated external to the TPM.
-  Chapter 10 explains the general process of creating primary keys, and Chapter 15 goes into even more detail.
-  Rolling the EPS also deletes any primary or descendent keys in the hierarchy.
-  Keys generated using the new EPS are cryptographically unrelated to those generated using the old EPS.