# Factory Reset **URL:** \ **Category:** General Discussions\ **Created:** [November 11, 2019, 11:03pm UTC](https://hub.mender.io/t/factory-reset/1234 "2019-11-11T23:03:08Z")\ **Posts on this page:** 14\ **Page:** 1
**Author:** ![Upgradio](https://avatars.discourse-cdn.com/v4/letter/u/b19c9b/32.png) [@Upgradio](https://hub.mender.io/u/Upgradio)\ **Post date:** [November 11, 2019, 11:03pm UTC](https://hub.mender.io/t/factory-reset/1234/1 "2019-11-11T23:03:08Z")
If a device has the option for a factory reset, is there a way to automatically have the device go back to the last deployed state? - Trevor ---
**Author:** ![mirzak](https://yyz2.discourse-cdn.com/flex036/user_avatar/hub.mender.io/mirzak/32/2056_2.png) [@mirzak](https://hub.mender.io/u/mirzak)\ **Post date:** [November 12, 2019, 7:46am UTC](https://hub.mender.io/t/factory-reset/1234/2 "2019-11-12T07:46:19Z")
Hello Trevor, welcome to the Mender community. There is currently no functionality that “automatically” triggers deployments based on certain conditions. Though this is a planed feature. With the current state you can solve this by utilizing the server API’s, and basically poll the list of the devices, looking up devices that have “factory\_reset=1” in e.g inventory (this is a value that you would need to add) and then you can create a deployment based on this lookup. ---
**Author:** ![Upgradio](https://avatars.discourse-cdn.com/v4/letter/u/b19c9b/32.png) [@Upgradio](https://hub.mender.io/u/Upgradio)\ **Post date:** [November 13, 2019, 12:42am UTC](https://hub.mender.io/t/factory-reset/1234/3 "2019-11-13T00:42:19Z")
Mirza, Trying to understand something here. Also for reset. Obviously want to avoid being double charged for same device. On a reset we don’t retain a **mender-agent.pem** and generate a new one. Would this be treated as a new activation? Cheers ---
**Author:** ![uttaravadina](https://avatars.discourse-cdn.com/v4/letter/u/e99b99/32.png) [@uttaravadina](https://hub.mender.io/u/uttaravadina)\ **Post date:** [November 13, 2019, 5:53am UTC](https://hub.mender.io/t/factory-reset/1234/4 "2019-11-13T05:53:44Z")
I have a similar question to @Upgradio 's. What are the possibilities of decommissioning/deactivating a device temporarily/permanently? ---
**Author:** ![mirzak](https://yyz2.discourse-cdn.com/flex036/user_avatar/hub.mender.io/mirzak/32/2056_2.png) [@mirzak](https://hub.mender.io/u/mirzak)\ **Post date:** [November 13, 2019, 8:19am UTC](https://hub.mender.io/t/factory-reset/1234/5 "2019-11-13T08:19:46Z")
> [@Upgradio](#): > > Obviously want to avoid being double charged for same device. On a reset we don’t retain a **mender-agent.pem** and generate a new one. Would this be treated as a new activation? ~~Yes, I believe this would be treated as a new device activation. The device identity has changed so there is no way to distinguish the two different cases.~~ Update: My initial answer was misdealing and wrong. We are counting devices which were active during the month but each active devices is always counted once (it’s safe to change auth set, rotate key etc) ---
**Author:** ![mirzak](https://yyz2.discourse-cdn.com/flex036/user_avatar/hub.mender.io/mirzak/32/2056_2.png) [@mirzak](https://hub.mender.io/u/mirzak)\ **Post date:** [November 13, 2019, 8:20am UTC](https://hub.mender.io/t/factory-reset/1234/6 "2019-11-13T08:20:35Z")
> [@uttaravadina](#): > > What are the possibilities of decommissioning/deactivating a device temporarily/permanently? Can you please clarify this question and what the use-case is. ---
**Author:** ![uttaravadina](https://avatars.discourse-cdn.com/v4/letter/u/e99b99/32.png) [@uttaravadina](https://hub.mender.io/u/uttaravadina)\ **Post date:** [November 15, 2019, 1:48pm UTC](https://hub.mender.io/t/factory-reset/1234/7 "2019-11-15T13:48:38Z")
Absolutely @mirzak 1. The use-case is if a Mender Node is compromised in any case, either physically or via the network, how can the Mender Server deactivate/decommission the device so that it doesn’t allow any requests to be processed by the compromised mender client and also see the deactivated/decommissioned device in the GUI. 2. Similarly, another use case can be when the deployed Mender Node needs to rotate/update its keys over a period of time. Can this be done remotely or manually? ---
**Author:** ![uttaravadina](https://avatars.discourse-cdn.com/v4/letter/u/e99b99/32.png) [@uttaravadina](https://hub.mender.io/u/uttaravadina)\ **Post date:** [November 15, 2019, 2:16pm UTC](https://hub.mender.io/t/factory-reset/1234/8 "2019-11-15T14:16:34Z")
@mirzak , I did find the solution the 1st use case. I didn’t look closely before. There are 2 ways that can be done. 1. Using mender-GUI the **Reject, dismiss or decommission the device** action can be used which appears in the Device-Identity section, whenever a device information is expanded in the All Devices section. 2. Using mender-cli, this API can be used to do the above same process [remove-selected-device](https://docs.mender.io/2.1/apis/management-apis/device-inventory#remove-selected-device) I also found a way to even execute the 2nd use-case and that is to use **Dismiss** option from the above mentioned. Could you please explain what happens if each of the **Reject, Dismiss or Decommision** is executed on the mender client using the GUI or mender-cli? ---
**Author:** ![mirzak](https://yyz2.discourse-cdn.com/flex036/user_avatar/hub.mender.io/mirzak/32/2056_2.png) [@mirzak](https://hub.mender.io/u/mirzak)\ **Post date:** [November 18, 2019, 9:14am UTC](https://hub.mender.io/t/factory-reset/1234/9 "2019-11-18T09:14:51Z")
> [@uttaravadina](#): > > Could you please explain what happens if each of the **Reject, Dismiss or Decommision** is executed on the mender client using the GUI or mender-cli? - **Reject** - Will invalidate the authorization of a specific authentication set and prevent that same set to be used again to authorize with the server. Essentially blocking the Mender client to connect to the server. - **Dismiss** - This will simply remove an authentication set associated with a device but it will not prevent the same authentication to be used for future authentication requests and the authetincation set would be in state “pending” if used again after **Dismiss** has been used - **Decommission** - This will simply remove the device and any associated authentication sets with a device but it will not prevent the same device to be used for future authentication requests and the authentication set would be in state “pending” if used again after **Decommission** has been used ---
**Author:** ![uttaravadina](https://avatars.discourse-cdn.com/v4/letter/u/e99b99/32.png) [@uttaravadina](https://hub.mender.io/u/uttaravadina)\ **Post date:** [November 18, 2019, 12:05pm UTC](https://hub.mender.io/t/factory-reset/1234/10 "2019-11-18T12:05:01Z")
Thank you @mirzak. That was very informative. So, in that case will it be possible to Reject a Device on the basis of a specific identity parameter or subset of identity parameters from the identity set. For example, **Macid** , **serial-id** , **ipv4** or all three of them ? ---
**Author:** ![mirzak](https://yyz2.discourse-cdn.com/flex036/user_avatar/hub.mender.io/mirzak/32/2056_2.png) [@mirzak](https://hub.mender.io/u/mirzak)\ **Post date:** [November 19, 2019, 8:37am UTC](https://hub.mender.io/t/factory-reset/1234/11 "2019-11-19T08:37:53Z")
> So, in that case will it be possible to Reject a Device on the basis of a specific identity parameter or subset of identity parameters from the identity set. For example, **Macid** , **serial-id** , **ipv4** or all three of them ? Identity is a combination of identity parameters and the public key. An authorization set is a combination of these. ---
**Author:** ![uttaravadina](https://avatars.discourse-cdn.com/v4/letter/u/e99b99/32.png) [@uttaravadina](https://hub.mender.io/u/uttaravadina)\ **Post date:** [November 19, 2019, 8:51am UTC](https://hub.mender.io/t/factory-reset/1234/12 "2019-11-19T08:51:03Z")
Then how can a device be rejected based on a specific identity parameter or N number of parameters? ---
**Author:** ![drewmoseley](https://yyz2.discourse-cdn.com/flex036/user_avatar/hub.mender.io/drewmoseley/32/47_2.png) [@drewmoseley](https://hub.mender.io/u/drewmoseley)\ **Post date:** [November 21, 2019, 11:16pm UTC](https://hub.mender.io/t/factory-reset/1234/13 "2019-11-21T23:16:55Z")
Rejecting a device is generally an operator-initiated action so you just choose the device you are interested in and reject it. It sounds like you are looking for a more programmatic approach which can certainly be done with the API. You can enumerate all the devices and the select the ones of interest based on your filtering criteria and the issue the API calls to reject them. We do not have a UI/automated way to handle this at present. ---
**Author:** ![uttaravadina](https://avatars.discourse-cdn.com/v4/letter/u/e99b99/32.png) [@uttaravadina](https://hub.mender.io/u/uttaravadina)\ **Post date:** [November 22, 2019, 4:40pm UTC](https://hub.mender.io/t/factory-reset/1234/14 "2019-11-22T16:40:02Z")
@drewmoseley yes. I think that in near-future this kind of use will be required as Mender is likely the go-to service for seamless OTA for embedded devices. The filtering approach you mentioned can be automated as well so that should pretty much do the job. Thank you!