It depends on the implementation of the token.
There is 3 types of implementations, and only first one is "vulnerable":
1: Some tokens are delivered where the seed can be calculated from the hardware serial in a determistic way. This can happen if you order a token where you can "use it with your own server without any need for API" or something similiar to that, something like a "universal TOTP token" or "universal HOTP token". You are then supposed to remove the sticker with the serial after having received the token, and usually the serial will be harder to guess.
In this case, someone with the knowledge of the serial will be able to calculate future codes.
2: You have ordered the token from the cloud service in question:
Then its no issue, as when your token is manufactured, a file with its serial numbers and secret seeds, are created and sent to your cloud provider. (Some token models even allow the cloud provider to "reinitialize" the token with their own seed)
Then, your cloud provider creates a database out of this file.
When you enter the serial on the cloud provider's site, they just look up the seed for that particular token and store that seed inside your account.
3: A token system with a API is used, where you order the token from a "token provider" that also provides a authentication API for third-party relying services to use:
Other token systems, like the Symantec VIP, instead relies on a API, where you only register the hardware serial with the cloud provider, only the serial is stored inside account. When a authentication happens, the cloud provider will send a request to the Symantec Server, asking if the code "xxxxxx" is a correct code to the token serial "xxxxxxxxxxxx". This is why a compromise cannot happen even if the same token are registred to multiple services.
And why you are asked to provide 2 subsuquent codes when registrering the token:
The reason you are asked to supply 2 subsuquent codes, is to ensure that the token is useable, so you don't accidentially lock yourself out of account. This process also works as a resync process, where the service will find the "initial sync" of the token, by searching for that particular window where these 2 codes exist, and the search could go through like tousands of codes to ensure that even a heavily desynced token can be registred with the service.
If only one code is supplied, theres a chance that the particular code exist somewhere else as 6 or 8 digits are pretty likely to repeat, and the server could accidentially set a wrong initial sync value to your token, leaving you locked out.
When you do a resync process, which can either be administrator/helpdesk initiated, or it can be a automatic process that is initiated by a number of invalid codes, you are aswell asked to provide 2 subsuquent codes. This time, its not to prevent a invalid resync as it is very unlikeable, but to increase security as the server will usually search about 50-100 codes forward, and also 50-100 codes backwards (configurable), which would make it likeable that a attacker could guess the code if only one was used, but of course the server will never go backwards past the last used code as this would allow reuse of token codes.
However, bottom line, is that you shouldn't share token serials anyway, because sometimes, the token serial can be partial authentication data for account recovery, so with the use of token serial, a attacker might be able to convince helpdesk personell into disabling 2FA for your account with like "My token have gone black, something is wrong with it" and such, and the helpdesk personell are just trying to help, and falling for the social engiinering trick.
