We do not store or process any payment information on our website. After you fill your order data, an order ID is created and passed to one of our payment processors (Stripe or PayPal). You only enter the credit card information on the payment page hosted by the payment gateway.
We normally do not provide free samples. If you want to test the functionality, feel free to use our virtual TOTP toolset. It fully emulates our hardware tokens.
Yes, our second-generation tokens support longer seeds generated by AlibabaCloud, AWS or Fortnite. Make sure you have the latest version (at least NFC Burner 2.1 for Android or NFC Burner 0.1 Advanced for Windows). Previous versions of the app do not support longer seeds.
All our token models support Azure Cloud MFA as long as your Azure AD license is P1 or P2. If you do not have any Azure AD license, you can still benefit from our tokens, but only the programmable ones. They act as a drop-in replacement of mobile authenticator apps (i.e. Microsoft Authenticator or Google Authenticator). This flowchart decision tree will help you to choose the right token model for your case.
Microsoft does not natively support TOTP authentication for the Active Directory. Azure Active Directory supports logging in with FIDO2 Security keys, but this is not really a multi-factor authentication. If you need to implement TOTP as a second factor for on-premise Azure Directory user authentication, we recommend the UserLock product from our partner, ISDecicions
Discounts are possible with orders starting from 50 units. To request a discounted quote, add the products to the basket, proceed with the checkout and at the final phase, click on Request quote button.
This depends on the authentication system itself. If the system supports importing the seeds (custom secret keys), then normally there is no limitation. For example, with Office 365 Azure MFA OATH TOTP feature, one token can be assigned to multiple users even within the same tenant. Right now Azure MFA does not check hardware token uniqueness at all (neither the serial number nor the seed), so, for instance, two users sitting in the same room may share a single token. Other services, like Google or Facebook, do not allow custom seeds to be imported, instead, they generate the seed at the server side and show it as a QR code and base32 string only once during the enrollment. These services are meant to be used with TOTP mobile apps on smartphones only, where users are supposed to scan the QR code using the phone to add the profile to the mobile authenticator app (such as Google Authenticator). Our programmable tokens can be used to eliminate the requirement of possessing a smartphone, the seed encoded in the QR code can be transferred to the programmable token so it can be used as a standalone TOTP device. (the process of transferring the seed to the token requires an Android phone or a Windows PC with NFC module- but this is for initial provisioning only, subsequent user logins can be done using the token only. So, with systems like Google Account, you cannot have one token assigned to more than one user, as there is no control over the seeds. There is, however, a theoretical possibility of using the token "programmed" to be used with a Google account with Azure MFA: you should save the base32 seed shown by Google when enrolling and import it to Azure MFA, so the seeds of Google and Azure MFA will be the same and therefore the same token can be used for both services.
DUO supports TOTP hardware tokens, but they have not fully implemented the time drift adjustment as per RFC6238. So, after some time, the tokens' hardware clock will become out of sync and the OTP codes will not be accepted by DUO authentication servers because of the system clock not matching. The time of the token then needs to be adjusted keeping the current seed intact. This is only possible with Token2 programmable tokens with unrestricted time sync: miniOTP-2 and OTPC-P1. Read more about using Token2 hardware tokens with DUO here.
Once the products are delivered, customers should request the secret keys by filling the form here. Please note that this is a manual process and will need to be reviewed by our team. The serial numbers of the tokens are required to be entered in the key request form. For tokens where the serial numbers are presented in barcode or QR code format, you can use the inventory apps to avoid entering the serial numbers manually. Please note that the seeds can only be sent to the emails specified when the order is placed. Keys requested in standard formats (Hex, Base32 or CSV for Azure MFA) are normally sent within one business day (CET timezone). After the secret keys are received, you should import them to your authentication system. See below the integration guides for some of the systems. Please note that you do not need to request secret keys for programmable tokens - you can set the keys yourselves using one of our burner apps
