Considering hardware tokens implementing OATH TOTP (c.f. [RFC6238](https://www.rfc-editor.org/rfc/rfc6238)), it is common knowledge that the clock in such tokens drift. A token that is not used very often is likely to drift way beyond the synchronisation window that an authentication server is using, hence resynchronisation may be required.

A simple form of resynchronisation is simply to widen the search window, and this may probably work in most cases. But if the search window is too large, there is a small risk that the token is wrongly synchronised (assuming an OTP is repeated). I have not done the math, but this is probably rare.

I have heard about resynchronisation methods that take a sequence of OTPs to resynchronise. This would give an accurate resynchronisation of course, but at the expense of having the user wait for two or three OTPs.

I know some token and authentication service providers have implemented a method where the user can get *partial* information about the clock in the display, so that the time information + OTP is used as input to the resynchronisation process.

I have not seen any of the OATH RFCs giving a concrete recommendation for how to resynchronise. I wonder if anyone on this forum knows of commonly used methods in the industry; in particular what is your view on the last variant I describe?