# Device and artifact security **URL:** \ **Category:** General Discussions\ **Created:** [February 12, 2020, 11:36am UTC](https://hub.mender.io/t/device-and-artifact-security/1534 "2020-02-12T11:36:50Z")\ **Posts on this page:** 1\ **Showing post:** 6
**Author:** ![SuicidalLabRat](https://yyz2.discourse-cdn.com/flex036/user_avatar/hub.mender.io/suicidallabrat/32/311_2.png) [@SuicidalLabRat](https://hub.mender.io/u/SuicidalLabRat)\ **Post date:** [February 13, 2020, 10:25pm UTC](https://hub.mender.io/t/device-and-artifact-security/1534/6 "2020-02-13T22:25:00Z")
Ultimately, secrets like keys should not be stored on the file system, for a myriad of reasons, not the least of which you have cited here. However, even given an encrypted artifact, a process like this presumes the secrets are the same for all nodes the artifact is being deployed to; which, second only to no security, is the bane of IoT’s future. I would much rather see effort in the road map targeting PKCS#11/HSM support - but then Im biased, as all our devices include security chips that we are not yet able to utilize with Mender. > [@PKCS11/HSM Support for authentication/authorization and signature verification](https://hub.mender.io/t/pkcs11-hsm-support-for-authentication-authorization-and-signature-verification/886): > > We have put significant resource into narrowing the attack surface of our device fleets, including the implementation of HSM type security/crypto modules to manage device secrets and PKI duties. The mender client is the sole component of our stack unable to leverage these security resources, where, as the highest risk vector for attacking our fleet, the OTA updating service should actually provide features supporting the highest level risk mitigation. Is there any intention to include HSM supp… SLR- --- _[View the full topic](https://hub.mender.io/t/device-and-artifact-security/1534)._