If you restart AM services on the Primary, either after a reboot or in Linux /opt/rsa/am/server/rsaserv restart all

the first time every token is used to logon after that, the AM server will accept any tokencode within a plus or minus 10 minute window. The AM server can then note any difference in the time on the token from the time on the AM server (which is always assumed to be correct)

Re-synching a token does the same thing, but with a plus or minus 12 hour window

To your original question, Next token Code, NTC can happen for two reasons, one of which is kind of what Support indicated to you, that this token is a little bit out of synch, the tokencode entered was within 2-3 minutes of the expected tokencode AFTER an initial authentication after restarting AM services. In other words, first time token used to authenticate after services have been started is the plus or minus 10 minute window, which allows AM to get its bearing on this individual token, to learn this token's exact time offset difference, and every time authenticating after that initial auth the Window is tighter, plus or minus 1 minute. Close as in plus or minus 2-3 minutes triggers NTC. Any tokencode more than 3 minutes off from expected offset time is considered incorrect and look even looked up.

The 2nd way to trigger NTC is to fail authentication some minimum amount of times, which is set in the Token Policy, and defaults to 3 failures in a row without a success - over any amount of time that the AM services have been running. You might consider a Token Policy change to 5 if this is a problem for your users, arguing that 5 is still tight enough to thwart hackers trying to steal OTPs (which in itself is an Everest-type task for the hacker).

You also can clear all NTPs from all Tokens with the /opt/rsa/am/utils/rsautil sync-tokens utility in Linux