Should a test/demo/non-prod system be prohibited from using the same HSM as production? Since the same master key would be used for both test and prod it seems like it could raise eyebrows but I can't find any specific guidance around this topic.
Sharing the same HSM(s) across multiple environments (e.g. dev, test, pre-prod, production) is the corporate equivalent of using the same password on multiple web sites.
Many large corporations periodically copy their production data into their QA/test environments. These lower environments typically have much less stringent data access controls in place. This means that if the same HSMs are in use in both locations, the data that had been properly protected in the production environment could possibly be improperly accessed in a non-production environment and then leaked to the outside world (or "exfiltrated", for those of you using Google to find this). So the defense against this is to ensure that there is no possible way in which the non-production systems can access the keys that the production systems used to protect the data. Which means separate HSM infrastructures for production and non-production.
And from a PCI perspective, if you can simply say to your auditors that your non-production environments simply have no way to access the keys used to protect the production data, that would save you more than the cost of the additional HSMs.
The big thing is this:
Although the HSM takes care of a lot of the management for you it doesn't relieve you of the obligations outlined in any standards you are working under.
I'm sure there is similar verbiage in any other standard that you'd be working under.
From a PCI-DSS Perspective:
In the PCI-DSS 2.0 standard, section 3.5.1 and 3.5.2b:
3.5.1 Examine user access lists to verify that access to keys is restricted to the fewest number of custodians necessary. 3.5.2.b Identify key storage locations to verify that keys are stored in the fewest possible locations and forms.
Generally speaking a QA environment has a much larger number of folks with access to the system, which would breach 3.5.1. If a breach in the QA system allowed for a breach in production I'm sure 3.5.2.b would also get pulled out.
One concern you may have with using a single HSM for different environments is that the key management requirements for the Dev/Test environments may not be consistent with the requirements of a production environment.
For example my understanding is that some HSMs can be placed in a "development or test" mode which may allow for key material to be retrieved from the HSM.
This might be desirable in a dev. environment for debugging purposes but would be extremely undesirable in a production environment.
So my conclusion would be that if the HSM is managed at all times as a production HSM, there shouldn't be any particular problem but that this could reduce its usefulness as a test/demo HSM...