In some cases, keys need to be distributed long after a system is initially set up. Being able to distribute keys securely is very important in these cases. The TPM design makes this easy. When each system is set up, a non-duplicable storage key is generated on the system, and a central system keeps a record associating this key with the system name (or perhaps the system serial number). This can be done in an Active Directory or LDAP database. Additionally, at provisioning time, the local platform gets a public key of the central system that corresponds to a signing key. At some later point, if the central system wants to distribute an HMAC key to the system, the following takes place:
1. The central IT system creates an HMAC key using
2. The central IT system encrypts the HMAC key with the public portion of the target client's storage key.
3. The central IT system signs the encrypted HMAC key with its private signing key. This is done so the local platform knows that what is being sent is authorized by IT.
4. The encrypted HMAC key is sent to the client along with a signature that proves it came from the central IT system.
5. The client verifies the signature on the encrypted key by loading the central server's public key. (This can be done with the TPM using TPM2_Load and then using TPM2_VerifySignature, if you like.)
6. The client imports the verified, encrypted HMAC key into its system using TPM2_Import, getting out a loadable, encrypted blob containing the HMAC key.
7. The client loads the HMAC key when the user wishes to use it, using TPM2_Load, and uses it as normal. At this point, the local platform has received an HMAC key from the IT central system that has never been decrypted in the local system's memory.
Because of the ability to create and re-create keys from the seed in the TPM, it's possible to use multiple key templates at provisioning time of a system and have a central IT system record the key template and corresponding public portion of the keys associated with the system. Central IT can then power cycle the TPM, destroying the system's copy of the key. Thus when the system is distributed to an end user, it doesn't have any of these keys available.
Later, when IT wants to activate those keys, it need only send the key template used
to create the key to the end user and allow the system to re-generate the key from the template using TPM2_CreatePrimary. Note that the key template includes the policy of
the key so generated, but not the password associated with it, which is chosen whenever the key is re-generated. If the central system wishes to avoid the use of that password when controlling the key, two bits in the template can be selected: userWithAuth and adminWithPolicy. These can be set in such a way as to make the password unable to control the key. If userWithAuth is set FALSE, and adminWithPolicy is set TRUE, then the password can't cause the key to perform any functions. 
In using this technique, the templates should be chosen in such a way as to include random entropy. Without the template, the key can't be re-created, so the central system can be sure the key isn't used until the template is received by the client.
There is another way to do key activation, similar to what was possible with TPM 1.2: using migratable keys. When a key is duplicated, you can doubly encrypt it:
once using the parent key of the system to which it's being duplicated, and once using a symmetric key that is inserted when the duplication is done. The produces a key blob that is encrypted twice. The outside encryption is gated by the new parent's private key. The inner encryption is done with a symmetric key. In this case, when a TPM2_Import command is executed, the TPM must have the private asymmetric key already loaded; its handle is given to TPM2_Import, and a secret is passed into the TPM2_Import command as a parameter. The secret is used in calculating the symmetric key, which in turn is used to decrypt the inner encryption. The command flow is as follows:
1. A duplicable key is generated on a central system.
2. The key is duplicated to the client system using the symmetric key option. This parameter is called encryptionKeyIn in the TPM2_Duplicate function.
3. The key blob is signed by the central system and sent to the client, but the encryptionKeyIn parameter is kept safe by the IT administrator.
4. When the IT administrator wishes to allow the key be used, encryptionKeyIn is provided to the client system,
allowing the client system to import it using the TPM2_Import
-  Because these flags are part of the template, if a user tries to change them, the user gets a different key.