SecurID® Discussions

Browse the SecurID discussion board to get product help and collaborate with other SecurID users.

Rsa secureid import

Jump to solution



Currently software tokens are expired and hardware tokens are not expired . I got the new token pack in a removable media .

1) So the question is how can I add  or  decrypt and import the new tokens to the system . 

2).There will be any impact on the current running hardware tokens 

3).What is token pack ID and where should I use the token pack id 



13 Replies





The scenario is 

I have  software and hardware tokens . Now the software tokens are expired .And ordered for new tokens .

(User A was using software tokens and it is expired and now I assigned hardware tokens to User A )

today I received software tokens from    RSA .

My question is If I am importing the new tokens does it affect the current hardware token users ?

a) Nothing will affect current users by simply importing more tokens on the system

( I mean does it affect the USER A ) .

second question 

If I have a hardware token and If it is expired do I need to  buy the new hardware  token device or just  renew  ? 

b) If you want to continue to use hardware token, you need to buy new ones and assign them or assign as replacements.

hardware tokens have no way to continue past the expire date etched on the reverse of the token itself.

You could assign software tokens as replacements to the expiring hardware token and get the software token to the end user. Just

note the restrictions on the 'pin number complexity' and 'type of software token' you distributed if you want the user to use

the old token pin with the new software token (if pins will transfer to the new token it makes token replacement more seamless)




1) you can import any tokens at any time, it has no affect other than you now have more tokens on the system that can be assigned. 


2) any user can have up to three active tokens assigned at any time, all with their own pin, and do not interfere with each other. most users have one token though...but three are technically possible.


3) in fact a user can have six tokens assigned at one time if you assign a replacement token to each existing token. a replacement token is when a token is about to expire, you can assign a replacement token, and the original token keeps working until it actually reaches the expire date, OR the user 'gets around to' using the new replacement token for the first time. By default when a user uses the replacement token for the first time, the original becomes unassigned.


4) when using the replacement token feature, the new token will inherit the old token pin number*, so the user just uses the new token with the old pin and it is pretty seamless. *if the new token can use such a pin....


5) If the original is a hardware token, and the replacement token is a software token, note that the PIN can only transfer seamlessly if the pin format used on the hardware token will work with the replacement token. example: I have a hardware token and a pin of new replacement token is distributed as PINPAD style software token. PINPAD software tokens have to use numeric pins only (because the pin is mathematically added to the tokencode, non-numeric characters in the pin won't work with PINPAD type tokens) , so I will need to set up a new pin for the new software token. But if the new software token is distributed as KEYFOB style, I can use the alphanumeric pin.


Software tokens are highly flexible by the admins, and you can distribute them as keyfob or pinpad style.


6) If the original token that is about to expire is a software token, and that software token has long expiration date of 2035 on the user device, but a normal expire date on the RSA Security Console, that indicates the software token originally was distributed from version 8.2 or higher, and it should have an extendable flag set on the Security Console when you look at assigned tokens. The extendable flag means you could 'extend' the old token with a new software token you recently imported, and the old token will inherit the new token expire date, the new token will be deleted, the old token will permanently be flagged as being 'extended by' the serial number of the new token, and the end user needs to do nothing...the token will keep working up to the new expire date recently inherited. Hardware tokens cannot be extended.


Here is an example: I have three old tokens from 2004. serial numbers 00020735xxx are a very old batch I had. I assigned and distributed them to users and of course they do not work, as they are all expired. But they did come from an system, therefore the expire date on the user device is in 2035. They work on the user device but the RSA Server denies authentication. So I went to my unassigned tokens where I have more recent non-expired tokens 00011603xxxx batch, and extended these old tokens. They will immediately start working for authentication, and are permanently marked with the serial number of the tokens they inherited the expire date from. Next time around I can extend these again and again as long as I have new unexpired software tokens to extend them with.




How can we unassign an extended  token ? 




Just unassign it. If you want to reset everything, delete the token from the system, then re-import the original seed record, and do not overwrite duplicates, the token will be imported normally and not extended. For the token that was used to extend a token that has been deleted from the system, you can reimport its original seed record to get it back as well.

Keep in mind that the token that was extended is probably expired by now, so re-importing the original seed for it probably won't give you a usable token.