new sw tokens compared to older sw tokens

[MarkDumond]

With 8.2 SP1, RSA's marketing indicates "new RSA SecurID Authenticate tokens are self-registered, automatically seeded, never expire."

Can someone explain how an older tokens lifetime compares to the lifetime of newer tokens both pre and post 8.2 sp1.

How does this affect recently purchased sw tokens added when pre-8.2 SP1, (added when on 8.2 p4) and prior to that when sw tokens were added at 8.1 ? Thanks for the help.

[Kenn_Chong · Accepted solution]

Hi Mark,

This feature is more about how and when the tokens are provisioned. The token records produced from RSA itself have not changed.

Prior to 8.2SP1, when you provision software tokens to the apps, the apps will display the actual life of the token and when it is time to renew a token, you would have to import a new token record into AM and then also have to re-provision the end-user's app.

With 8.2SP1 and later, the first time you provision to the app, the app will now display a "long life" end date (year 2035), but AM will still contain the actual expiration date of the software token itself. When it is time to renew the end-user's token, all you need to do is import a new token into AM, and AM will only update the expiration date on the server side and you will not need to touch the user's app any longer. This now makes it easy for you as the AM admin to renew software tokens going forward as the end user's app will keep generating OTPs and will never stop functioning. The server side will be keeping track of when the user's OTP is valid or not based on the expiration date that it is keeping track of.

Hope this helps!

[EdwardDavis]

To add to Kenn Chong comment...

A software token that was distributed from an 8.1.x system, will not have the long expire date. So, if you started on 8.1, and now have patched up to 8.2.x, you would still need to redistribute a user software token at least once, so the 8.2.x system can 'stamp it' with the long expire date, and also set an 'extendable' flag for the token. 

Any token with an extendable checkmark means: it is currently assigned to someone, and it came from an 8.2.x system, and it's expire date can be bumped out indefinitely by inheriting new tokens expire dates, until the final terminate_date (which in the current patch level today is Dec 2035).

[MarkDumond]

Thanks for your help.

Prior to going to 8.2 sp1 p3, i was running 8.2 p4. Prior to that 8.1. 

Back in February, new sw tokens were added to our system - and noticed now the RSA app on the smartphones do show 2035 as the expiration date yet the lifetime for the token in the AM database shows it ends on March 30, 2020.

Since these tokens are new and have been distributed once, under 8.2 p4, i assume they have the proper flagging in place.  Once we approach March 30, 2020, what steps are necessary to extend the "existing" sw tokens to a later date.

Database shows token lifetime - Started on Feb 27, 2017 7:00:00 PM EST Ends on Mar 30, 2020 8:00:00 PM EDT

[EdwardDavis]

Just go to the token you want to extend,

and the dropdown menu has new options to extend it.

If you

a) are within 15 days of the token expiring (this 15 day window can be changed using a command line procedure)

b) and have unassigned software tokens not yet expired

The system will go fetch a token and ask if you approve of the one it selected,

and then it will extend the current token with it's own expire date, the newer token will

become deleted from the system, and from now on when you look at the original token,

it will have a column 'extension token' showing the token that was used to extend it's expire date.