Need to transfer ownership of hardware token back to RSA Authentication Manager

[scarmin1]

In order to try and manage the hardware tokens via the SecurID cloud dashboard, I transferred the imported hardware tokens from the RSA Authentication Manager to the cloud. That was successful, however the cloud dashboard does not have the option to not require a PIN. That option fails in the RSA Authentication Manager because the tokens are now managed in the cloud.

Is there a way to transfer the tokens FROM the cloud back to the Authentication Manager?

OR

Is there a way in the cloud dashboard to not require a PIN for the hardware tokens? That way one person can assign and unassign tokens without the end user involvement.

I have already opened a support case, but wanted to ask here as well. Transferring ownership of the hardware tokens to the cloud was a mistake, but I didn't realize that I couldn't assign them to users in the cloud dashboard without a PIN.

[EricaChalfin · Accepted solution]

@scarmin1,

Great question! Per page  95 of the Authentication Manager 8.7 Administrator's Guide:

Transfer SecurID 700 Hardware Token Ownership to the Cloud Authentication Service
You can transfer ownership and administration of assigned and unassigned SecurID 700 hardware tokens from
RSA Authentication Manager to the Cloud Authentication Service. You select which token records are transferred, and you initiate the transfer. After the token records are transferred to the cloud, Authentication Manager no longer manages the tokens and can not take back ownership [emphasis added].

That said, if you still have the token seeds, you could try deleting them from CAS, importing them back into Authentication Manager then reassigning them back to your end users.

With regard to PIN-less hardware tokens in the CAS; as you have noted, that is not currently supported. I'd suggest posting this suggestion to the SecurID Ideas Exchange. This puts your idea to a vote. PM then reviews these ideas and decides if they merit inclusion in a future release.  Just note that single-factor OTP is inherently insecure and it is something we discourage. With the move to passwordless, AD password can no longer be assumed as the first factor. This makes it even more critical to protect hardware tokens with a second factor. The FIDO Alliance has come to the same conclusion, For example, FIDO2 specs now require PIN when FIDO is used as the first factor.