You are using an unsupported browser. Please update your browser to the latest version on or before July 31, 2020.

Looking for the Diagnostic Utility?

Click Here For Download and Usage Instructions

Google Authenticator/Mobile App OTPs Rejected


PortalGuard always rejects OTPs generated by a mobile authenticator app (e.g. Google Authenticator, Authy, Microsoft Authenticator). This could occur during initial enrollment of the mobile app or well after it was enrolled.


There are a few reasons why a PortalGuard server will reject Time-Based One Time Passwords (TOTPs) from a mobile app. If the user's mobile app is generating TOTPs for PortalGuard, the simplest thing to check first is to ensure the user's PG User Profile actually contains data related to a mobile authenticator. For an end-user, this can be done by logging into the PG Account Management page (this may only be possible if they have alternate 2FA methods). If PG has mobile app data for the user, the "Mobile Authenticator" section on the Account Management page will appear with a timestamp in the Enabled On field as shown below:

Administrators and IT Help Desk can use the User Detail Lookup available in the Admin Dashboard to see this information as well:

After eliminating the lack of server-side mobile app data as a possibility, you can move on to the more involved troubleshooting which involves possible clock skew on the PG server.

Mobile authenticators like Google Authenticator, Authy and others generate TOTPs based on an internet standard described in RFC 6238. The relevant point is that the current time is part of the algorithm to generate and verify TOTPs. Clock differences as little as 30 seconds between the PG server and mobile phones will cause the algorithm to produce different TOTP values, resulting in failed verifications.

Mobile phones receive the current time from their phone providers so it can be safely assumed that the time on the mobile phone is accurate. The use of virtualization has made clock skew of VMs commonplace (link1, link2, link3). This is countered by having servers continually update their system clock from a Network Time Protocol (NTP) server. For Windows servers joined to an Active Directory domain, they automatically pull their time from domain controllers. However, if domain controllers are not able to set their own time from an externally accurate source (e.g. or, it is possible for an entire domain of machines to have incorrect time!

First check the PortalGuard server's clock against an authoritative source like If the PG server clock is 30 or more seconds off (slow or fast), then it will need to be corrected using the following steps:

NOTE: The procedure below will cause your PG server to synchronize its time from an external NTP server. If the root problem is an incorrect clock on a domain controller (DC), the following steps can be performed on DCs as well but you should check with your system administrators before making any changes to DCs.

  1. Login the PortalGuard server as an administrator and run regedit.exe
  2. Navigate to the key HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\W32Time\Config
  3. Change the AnnounceFlags REG_DWORD value from 10 to 5
  4. Navigate to the key HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\W32Time\Parameters
  5. Change the NtpServer REG_SZ value to:,0x1
  6. Change the Type REG_SZ value from NT5DS to NTP
  7. Open an administrative command prompt and restart the Windows Time Service with the following command:
    • net stop w32time && net start w32time
  8. In the same command prompt, run the following command to force the system to sync its time immediately:
    • w32tm /resync /rediscover

The time on the PortalGuard server should now match what is shown on Try to submit a TOTP from the mobile authenticator again and PortalGuard should be able to verify it.

If the steps in this article do not resolve the problem, please contact us at to work with an engineer.

REV. 01/2020 | PortalGuard

  • 115
  • 10-Jan-2020