OTP codes created using a time-based solution (e.g. using a SafeID/Classic token) will obtain the current time using an internal clock that updates its time based upon oscillations of a quartz crystal. The crystal allows the device to keep relatively accurate time, but you can still expect the clock to drift by approximately one second every three days. Over the space of a year this drift can vary, but you expected time drift would be in the order of a couple of minutes.
If you are using the clock of a non-network connected PC or laptop, then the expected drift will be more likely to be 6 minutes per year or more. For networked computers this drift can be mitigated by ensuring that the computers clock is synchronised either with internet time, or with the time on the domain controller.
Time drift is not expected on mobile devices as they tend to have clocks synchronised with the mobile network carrier (and therefore should be expected to be within a few seconds of true time).
Time drift on the authentication server is also possible, but can be resolved by ensuring the servers clock is synchronised with an external reliable time server.
If the difference reported by the clocks on the client and on the server differ by more than the size of the time window (normally 30 or 60 seconds), then the OTP code generated by the client will not match the OTP code generated by the authentication server, and authentication may fail.
When the OTP code generated by a hardware token is failing to be accepted by the authentication server, it is possible to check the extent of any existing time drift using the following procedure;
There are two main solutions to resolve issues caused by time drift;
When authentication apps are used to produce the OTP code (such as SafeID authenticator and MobileID authenticator), then the clock is provided by the host computer, and when using an app on a PC, tablet or laptop, then the clock can normally be corrected by synchronising time with an internet based time server.
For hardware tokens (such as the SafeID range of TOTP tokens), the internal clock may only be corrected if the token is a programmable token, and can be corrected using the following procedure;
If you are not able to correct the clock on your device, then you need the server to account for your existing time drift, and this can often be achieve by performing a time synchronisation between the server and the token.
Time synchronisation for pre-programmed hardware tokens will occur either during the registration process of the token (for example when registering a token with azure), or using a separate process provided by the authentication server (where typically two consecutive OTP codes will be requested).
Given time drift occurs on hardware tokens regardless of use, we suggest registering you token with you authentication server within the first year of purchase. The majority of the hardware tokens we supply are programmed with 60 second time windows, and most authentication servers can deal with a few time windows of drift prior to registration. When registering older tokens with azure we suggest manual registration rather than bulk registration.
If your OTP codes are produced by an app running on windows, then ensure the clock on your computer is automatically synchronised with an external and reliable time server.