To exchange cryptographic keys, first store the session key outside the CSP because CSPs do not preserve session keys between sessions.
This transfers the session key from the CSP to your application memory space. Specify that your own key exchange public key be used to encrypt the key BLOB.
If you plan to use the session key for encryption later, the key BLOB should be signed with your key exchange key before the key is stored. When you read the key BLOB later, validate the signature to be sure the key BLOB is intact. If these steps are omitted, someone with access to your storage media can create their own session key, encrypt it with your key exchange public key, and substitute it for your key BLOB. You could then unknowingly use their session key to encode files and messages, which the unauthorized user could decode.
As an alternative to storing a random session key BLOB, you can use a derived session key, created from a password using the CryptDeriveKey function. In this way, instead of storing a particular derived key, an application can create a derived key as needed by prompting the user for the password.
A stored key BLOB is dependent on the stability of the public and private key pairs stored within the CSP. If these key pairs are lost through a hardware or software incident, for example, you will be unable to decode your key BLOB. Any data encrypted using these keys will also be lost. For this reason, a user should consider using a backup authority when storing long-term archival data.