This integration guide discusses strategies, rather that provide direct integration steps.
The SecurityServer libraries provide two methods for storing and managing keys, internally (on the HSM) and externally. For this integration guide, these are collectively referred to as the 'managed keystores'.
Internally managed keys are stored in and read from the CXIKEY.db database. All internal keys -- regardless of which standard API is used -- are stored and used via the CXI module (the host-side API is a bridge to CXI).
Externally managed keys are stored in a flat-file database, someplace accessible to the hist libraries (SAN, RAID, local file system, etc).
Where an enterprise will store its cryptographic keys for use with the CryptoServer, depends on the architecture and use-case. Each application can use its own strategy for storage and use. A root CA ('certificate authority') will probably maintain the Root Key using the internal key store, while signing keys, subordinate/issuing CAs and such may store their keys externally. It all depends on the enterprise's security posture, policies and procedures.
Managed keystores are directly supported by the SecurityServer libraries, whether internally or externally.
Each of the managed keystores has limitations on the number of keys that can be physically or reasonably supported.
The internal database is limited to 8Mb of key data. Each key object (or "row" in the internal database) contains structural, meta and sensitive key information, so a "key" may be longer or shorter than expected, and you may be storing information like a certificate, etc with a key. While backup and restore of the database is simplified by the csadm/CAT tools, it is still an extra step to perform regular backups.
The external database is limited to the file-size limit of the storage file system in use. While this means that the number of keys is effectively unlimited, the reality is that the more keys you have, search, retrieval and key synchronization between applications can make larger key databases unwieldy. On the other hand, backup strategies are straightforward, and can be transparent to the user.
The rule of thumb is if an application has more than 100 keys to worry about, consider the internal database. If it has 10,000 keys to worry about, the external keystore is suitable.
But, what happens when you are providing keys to an IoT implementation, and you are talking about 100,000, or 1 million, or 100 million asymmetric key pairs?
In this case, you should consider managing the keys yourself, within your own application -- by making use of enterprise systems that are designed up front for this use case: RDBMS, or KMIP (Key Management Interoperability Protocol) systems.