Moving a signing key into an HSM changes where the key material lives. It does not automatically decide which application, workload, or operator may use that key for a particular purpose. PKCS#11 provides object attributes and authentication controls, but the security result depends on how an application exposes those controls.
The PKCS#11 specification describes attributes such as CKA_SIGN, CKA_DECRYPT, CKA_SENSITIVE, and CKA_EXTRACTABLE. These restrict operations on a key object. CKA_ALWAYS_AUTHENTICATE can require the user to supply a PIN for each use of a private key. The setting is useful for higher-assurance signing, but it does not establish that the requested operation is authorized for the business transaction.
The HSM is not the policy engine
A token may accept a signature because the application has authenticated with a PIN and the key permits C_Sign. It does not know whether the caller should be allowed to sign a payment instruction, issue a certificate, or decrypt a client secret. That decision belongs in the calling service, backed by workload identity, authorization policy, request validation, and an audit trail.
Applications often collapse several keys or operations into one service account. The resulting design can be technically compliant with PKCS#11 while leaving a broad interface exposed to every caller that reaches the signing service. A key marked non-exportable can still produce unlimited signatures if the service around it accepts untrusted input.
Certificate key usage and PKCS#11 operations are related but not interchangeable. A certificate may permit digital signatures, while the application has no business signing every document it receives. Conversely, an HSM operation that is allowed by policy may still violate an internal approval control. Test the complete path from request identity to key object.
Make the boundary explicit
First inventory every key object by purpose, owner, token, and calling service. Record the permitted mechanisms and attributes in a configuration baseline. Then verify that the application has a separate authorization decision for each sensitive purpose. Do not let a shared admin role, generic signing endpoint, or environment variable become the de facto key owner.
Use CKA_ALWAYS_AUTHENTICATE where re-authentication supports the risk model, but test the operational consequence. A background signer may fail when a human is unavailable, while a poorly designed workaround may cache the PIN and defeat the intent. Keep authentication material out of logs and ensure that repeated-use caches are short-lived and scoped to one process.
Finally, exercise the negative cases. Attempt an operation that the key attributes forbid. Attempt an allowed operation with the wrong caller identity. Confirm that both events produce distinct audit evidence. A protected key is valuable only when the surrounding service can explain why each use was authorized.