Authyo Docs
    • 🐶 Walk through Authyo
    • Error Codes
    • About Pricing
    • Authyo RDP Guard — Windows Install Guide
    • APIs
      • Send OTP
        GET
      • Send OTP
        POST
      • Verify OTP
        GET
      • Verify Token
        POST
      • Revoke User Session
        POST
    • Web SDKs
      • JavaScript
      • PHP
      • AngularJS Examples
      • TypeScript Examples
      • React JS
      • Vue JS Examples
    • 2FA SDK
      • JavaScript
      • AngularJS Examples
      • PHP
      • React JS
      • TypeScript Examples
      • Vue JS Examples
    • Native/Mobile SDKs
      • Flutter
    • Integration
      • Google Sheet
      • Firebase
    • Session Management
      • Introductions
      • JWT Token
    • Notifications
      • Notifications Order
      • Notificatoin Invoice

    Authyo RDP Guard — Windows Install Guide

    Version: 1.0.0
    Released: May 2026
    Verified on: Windows 11 23H2 and Windows Server 2022 (both Workgroup) ✅
    Other supported OS: Windows 10 22H2, Windows Server 2019 / 2025, Windows 11 24H2
    Authyo RDP Guard adds an OTP challenge to the Windows logon screen and to Remote Desktop sessions. After install, every interactive sign-in requires both a valid Windows password and a one-time code that goes to one or more pre-configured admin contacts.
    This document is the single canonical guide — read top-to-bottom on first install. After that you can jump to specific sections by the table of contents.

    Contents#

    1.
    Read this before installing
    2.
    Pre-install checklist (run the 30-second self-check first)
    2.1 The machine
    2.2 .NET 8 Desktop Runtime
    2.3 Two local administrator accounts
    2.4 Network reachability to app.authyo.io
    2.5 RDP-specific requirements (NLA, firewall, ports, RDS)
    2.6 Authyo backend prerequisites
    2.7 Optional but recommended
    2.8 Self-check script (paste-and-run)
    3.
    What the MSI installs
    4.
    Install — step by step
    4.4 Configurator (Authyo credentials → admin contacts → delivery policy → trust window → test → save)
    5.
    Using Authyo RDP Guard with Remote Desktop
    6.
    Day-to-day usage
    7.
    Troubleshooting
    8.
    Common failure modes — quick reference
    9.
    Disaster recovery
    10.
    Uninstall
    11.
    Security notes
    12.
    Support

    1. Read this before installing#

    Authyo RDP Guard installs as a Windows Credential Provider — it participates in the OS sign-in flow. While the installer is small and the uninstall is clean, you should:
    1.
    Pilot on one server first. Don't roll out to the whole fleet on day one. Install on a single staging machine, sign in via the new tile a few times, then expand.
    2.
    Keep a second local Administrator account active before installing. If the Authyo tile doesn't work for any reason, you can sign in via the standard password tile or via Safe Mode with the rescue account.
    3.
    Have a backup or snapshot if you're paranoid. Windows Server doesn't ship System Restore; use Windows Server Backup or your hypervisor's snapshot feature.
    If anything goes wrong at the logon screen: Safe Mode → sign in as the rescue admin → Settings → Apps → Authyo RDP Guard → Uninstall. Full disaster recovery in section 9.

    2. Pre-install checklist#

    Run through this before installing the MSI on any Windows server. A failing item here is the most common cause of "Authyo tile doesn't appear" or "RDP signs me in without OTP" tickets. The checklist takes about 10 minutes and saves 1–2 hours of post-install diagnosis.
    If you just want go/no-go: jump to the self-check script in section 2.8 — it runs every check in ~30 seconds.

    2.1 The machine#

    RequirementWhy it mattersHow to check
    Windows 10 22H2, Windows 11 23H2 / 24H2, Windows Server 2019 / 2022 / 2025Credential Provider API + KERB_INTERACTIVE_UNLOCK_LOGON struct are stable across these. Older Windows (7, 8, Server 2016) ships an older CP API and is not supported.winver or (Get-CimInstance Win32_OperatingSystem).Caption
    64-bit (x64) architectureThe MSI ships only x64 binaries. ARM64 and x86 Windows are not supported in v1.0.0.[Environment]::Is64BitOperatingSystem must return True
    Administrator rights at install timeMSI writes to HKLM\SOFTWARE\Classes\CLSID\…, registers a Credential Provider, and writes to C:\Program Files\…. All require admin.Run PowerShell as Administrator
    At least 50 MB free disk on system driveInstall is ~3 MB but DPAPI working files, trust.db, and logs grow over time.(Get-PSDrive C).Free > 50 MB
    Unsupported OS: the MSI may install (no version gate enforced), but the Credential Provider may not load, the tile may not render, or sign-in may crash LogonUI on unsupported OSes. Do not deploy to production on unsupported Windows.

    2.2 .NET 8 Desktop Runtime — required#

    The MSI does not bundle the .NET runtime. Without it, Authyo's DLLs cannot load inside LogonUI; the Credential Provider DLL stays registered but produces no tile.
    Check:
    dotnet --list-runtimes
    You must see this exact line (version may be 8.0.x):
    Microsoft.WindowsDesktop.App 8.0.27 [C:\Program Files\dotnet\shared\Microsoft.WindowsDesktop.App]
    Install — option A (winget):
    winget install Microsoft.DotNet.DesktopRuntime.8 `
        --accept-source-agreements --accept-package-agreements
    Install — option B (direct download): https://dotnet.microsoft.com/en-us/download/dotnet/8.0 → .NET Desktop Runtime 8.0.x → Windows x64 Installer → run.
    After install, open a NEW PowerShell window (PATH doesn't update for existing sessions) and re-run dotnet --list-runtimes.
    Why specifically the Desktop Runtime? The Configurator is a WPF app. The Credential Provider's bridge loads Microsoft.WindowsDesktop.App inside LogonUI. The "ASP.NET Core" or "Server" variants of .NET 8 are not sufficient and will produce silent load failures.

    2.3 Two local administrator accounts — required#

    You must have at least two local administrator accounts on the server before installing. One is your usual admin; the second is a "rescue" account you only use if something breaks at the logon screen.
    Create the rescue admin:
    $pw = Read-Host -AsSecureString 'Password for rescue admin (write it down!)'
    New-LocalUser -Name 'gk-rescue' -Password $pw `
                  -PasswordNeverExpires `
                  -Description 'Authyo RDP Guard emergency rescue admin'
    Add-LocalGroupMember -Group 'Administrators' -Member 'gk-rescue'
    Verify the rescue admin works BEFORE installing the MSI:
    1.
    Press Win + L to lock the screen.
    2.
    Sign in as gk-rescue with the password you set.
    3.
    Confirm sign-in succeeds.
    4.
    Sign back into your normal admin account.
    If the rescue admin sign-in fails — do not install the MSI until you fix it. You have no safety net otherwise.
    Rescue admin requirements:
    Local account (not domain — domain accounts may not be reachable in isolated recovery scenarios)
    Member of the Administrators group
    Password written down somewhere reachable from another device (your phone, a password manager, paper) — if you lose it and get locked out, only console / safe-mode boot can recover

    2.4 Network reachability to app.authyo.io#

    # DNS resolution
    Resolve-DnsName app.authyo.io
    
    # HTTPS reachability
    $r = Invoke-WebRequest 'https://app.authyo.io/' -UseBasicParsing -TimeoutSec 5
    "HTTP status: $($r.StatusCode)"   # expect 200 (or 404 — both prove reachability)
    Both must succeed. If they don't:
    DNS fails — check the server's DNS settings; confirm your firewall doesn't block outbound port 53.
    HTTPS fails — check outbound port 443 isn't blocked; check that any corporate proxy or SSL-inspection appliance trusts the Authyo certificate.
    Slow timeout — the Authyo client uses a 10-second HTTP timeout by default. This can be raised up to 30 seconds in config.json → authyo.timeoutSeconds.
    Behind a proxy: the Authyo client uses System.Net.HttpClient which honors the system proxy (netsh winhttp show proxy). For most corporate proxies the default behavior is fine. For proxies that require client certificates or NTLM auth — contact support@authyo.io.

    2.5 RDP-specific requirements#

    If you intend to use Authyo RDP Guard to gate RDP logons (not just local console sign-in), the following are non-negotiable.

    2.5.1 Network Level Authentication (NLA) must be disabled#

    NLA pre-authenticates RDP clients via CredSSP at the TCP layer before Windows LogonUI ever loads. While NLA is on, the Credential Provider is never invoked for RDP — the MFA gate is silently bypassed.
    Check current NLA state:
    (Get-CimInstance -Class Win32_TSGeneralSetting `
        -Namespace root\cimv2\TerminalServices `
        -Filter "TerminalName='RDP-tcp'").UserAuthenticationRequired
    # 1 = NLA on  (bypasses Authyo)
    # 0 = NLA off (Authyo tile fires)
    Disable NLA:
    (Get-WmiObject -class Win32_TSGeneralSetting `
        -Namespace root\cimv2\TerminalServices `
        -Filter "TerminalName='RDP-tcp'").SetUserAuthenticationRequired(0)
    Tradeoff: NLA was designed to reduce the server's pre-login attack surface for brute-force RDP. With NLA off, every TCP connect spins up a LogonUI session on the server — slightly heavier and slightly more reachable.
    Recommended mitigation when NLA is off:
    Firewall RDP (port 3389) to known IPs only, or behind a VPN / bastion.
    Don't expose RDP directly to the public internet — use RD Gateway, Tailscale, ZeroTier, or a managed bastion.
    Keep policy.blockOnAuthyoUnreachable = true in config.json (the default) — fail-closed if Authyo is unreachable.

    2.5.2 Windows Firewall rules#

    Get-NetFirewallRule -DisplayGroup 'Remote Desktop' |
        Select DisplayName, Enabled, Profile
    All three (Domain / Private / Public) rules should be Enabled = True for the profile where your clients connect from.

    2.5.3 Do NOT change the RDP port without a firewall rule first#

    Changing HKLM\SYSTEM\CurrentControlSet\Control\Terminal Server\WinStations\RDP-Tcp\PortNumber without first adding a Windows Firewall inbound rule for the new port locks RDP out. If you want to move RDP off 3389:
    # 1. Add the firewall rule for the new port FIRST
    New-NetFirewallRule -DisplayName 'RDP (custom port 33899)' `
        -Direction Inbound -Protocol TCP -LocalPort 33899 -Action Allow
    
    # 2. THEN change the port
    Set-ItemProperty -Path 'HKLM:\SYSTEM\CurrentControlSet\Control\Terminal Server\WinStations\RDP-Tcp' `
        -Name PortNumber -Value 33899
    
    # 3. Test from a SECOND mstsc window BEFORE restarting TermService
    mstsc /v:server-ip:33899
    
    # 4. Once the new port works, restart the service
    Restart-Service -Name TermService -Force

    2.5.4 If you use Remote Desktop Services (RDS) collections#

    For RDS Session Hosts behind a Connection Broker, the Credential Provider installs on the Session Host, not on the Connection Broker or RD Gateway. The gating happens at the Session Host's LogonUI. NLA must still be disabled on the Session Host.

    2.5.5 If you use Microsoft Account (MSA) sign-in#

    Authyo RDP Guard is designed for local Windows accounts and Active Directory domain accounts (Kerberos / NTLM). It does not wrap the Microsoft Account sign-in tile. MSA users continue to use the standard MSA sign-in tile, which is left visible.

    2.6 Authyo backend prerequisites#

    RequirementWhyHow to verify
    Active Authyo application with a valid Client ID + Client SecretConfigurator wizard needs these to fetch OTPs.Portal → Applications → confirm the app is Active and has both credentials.
    Auth priority configured for every channel you'll use (Email / SMS / WhatsApp / Voice Call)Backend rejects SendOTP if the application doesn't have an auth priority set for the channel. If you have 3 contacts with mixed channels, every channel needs its own priority.In the app's settings, each channel must show Active = ON and Priority = 1 or higher.
    One or more reachable contacts (real email inbox or real phone)Without working contacts, OTPs are sent but never received.Test with the Send test OTP button in the Configurator wizard.
    Sufficient wallet balance in your Authyo accountEvery OTP delivered debits your wallet (per-OTP, no subscription). If you use the AllInOrder policy with N contacts, each sign-in debits N OTPs.Portal → Billing → wallet balance.
    No active OTP rate limits for the target contactsBackend rate-limits SendOTP per (app, contact) pair to prevent abuse.If you hit a limit during testing, wait ~30 seconds and retry.

    2.7 Optional but recommended#

    Save a system image / backup. Windows Server doesn't ship System Restore. For paranoia, use Windows Server Backup:
    Install-WindowsFeature Windows-Server-Backup -IncludeManagementTools
    # Then Server Manager → Tools → Windows Server Backup → Backup Once → System State
    Takes 20–30 minutes; needs a separate drive with ~30 GB free.
    Document the rescue admin password somewhere unreachable from the server. Phone notes, password manager, a piece of paper in your office desk.
    Test on a non-production server first. A snapshotted Hyper-V VM, a staging Server 2022 with no live customers, or a spare physical box. Don't make your first install on the business-critical machine.

    2.8 Self-check script#

    Copy-paste the entire block below into an elevated PowerShell on the server. It runs every check in sections 2.1–2.5 in ~30 seconds and prints a green/red summary.
    # ============================================================
    # Authyo RDP Guard — pre-install self-check
    # Paste this whole block into an elevated PowerShell window.
    # ============================================================
    
    $results = New-Object System.Collections.ArrayList
    function Test-Item {
        param([string]$Name, [scriptblock]$Check)
        try {
            $ok, $detail = & $Check
            $results.Add([PSCustomObject]@{
                Item   = $Name
                Status = if ($ok) { 'PASS' } else { 'FAIL' }
                Detail = $detail
            }) | Out-Null
        } catch {
            $results.Add([PSCustomObject]@{
                Item = $Name; Status = 'FAIL'; Detail = "ERROR: $_"
            }) | Out-Null
        }
    }
    
    # 1. OS & arch
    Test-Item 'Supported Windows version' {
        $caption = (Get-CimInstance Win32_OperatingSystem).Caption
        $build   = [int](Get-CimInstance Win32_OperatingSystem).BuildNumber
        @($build -ge 17763), "$caption (build $build)"
    }
    Test-Item '64-bit OS' {
        @([Environment]::Is64BitOperatingSystem),
            "x64: $([Environment]::Is64BitOperatingSystem)"
    }
    Test-Item 'Administrator rights' {
        $id = [Security.Principal.WindowsIdentity]::GetCurrent()
        $isAdmin = (New-Object Security.Principal.WindowsPrincipal($id)).IsInRole(
            [Security.Principal.WindowsBuiltInRole]::Administrator)
        @($isAdmin), "Elevated: $isAdmin"
    }
    Test-Item 'Free disk > 50 MB on C:' {
        $free = (Get-PSDrive C).Free / 1MB
        @($free -gt 50), "$([math]::Round($free, 0)) MB free"
    }
    
    # 2. .NET 8 Desktop Runtime
    Test-Item '.NET 8 Desktop Runtime' {
        $runtimes = (& dotnet --list-runtimes 2>$null) -join "`n"
        $has = $runtimes -match 'Microsoft\.WindowsDesktop\.App\s+8\.'
        @($has), $(if ($has) { 'WindowsDesktop.App 8.x present' } else { 'MISSING - install from https://dotnet.microsoft.com/download/dotnet/8.0' })
    }
    
    # 3. Rescue admin
    Test-Item 'At least 2 local administrators' {
        $adminCount = (Get-LocalGroupMember Administrators |
                       Where-Object { $_.PrincipalSource -eq 'Local' }).Count
        @($adminCount -ge 2), "$adminCount local admin(s) - recommend gk-rescue as a 2nd account"
    }
    
    # 4. Network reachability
    Test-Item 'DNS resolves app.authyo.io' {
        try {
            $null = Resolve-DnsName app.authyo.io -ErrorAction Stop
            @($true), 'OK'
        } catch { @($false), "DNS failure: $_" }
    }
    Test-Item 'HTTPS reachable to app.authyo.io' {
        try {
            $r = Invoke-WebRequest 'https://app.authyo.io/' `
                    -UseBasicParsing -TimeoutSec 5 -ErrorAction Stop
            @($true), "HTTP $($r.StatusCode)"
        } catch {
            if ($_.Exception.Response) {
                @($true), "HTTP $([int]$_.Exception.Response.StatusCode) (reachable)"
            } else {
                @($false), "Unreachable: $($_.Exception.Message)"
            }
        }
    }
    
    # 5. RDP / NLA
    Test-Item 'NLA disabled for RDP (required for MFA gate)' {
        $nla = (Get-CimInstance -Class Win32_TSGeneralSetting `
            -Namespace root\cimv2\TerminalServices `
            -Filter "TerminalName='RDP-tcp'").UserAuthenticationRequired
        $msg = if ($nla -eq 0) {
            'NLA off - Authyo tile will fire on RDP'
        } else {
            "NLA ON - RDP will BYPASS Authyo OTP gate. Disable with: (Get-WmiObject Win32_TSGeneralSetting -Namespace root\cimv2\TerminalServices -Filter `"TerminalName='RDP-tcp'`").SetUserAuthenticationRequired(0)"
        }
        @($nla -eq 0), $msg
    }
    Test-Item 'Remote Desktop service running' {
        $svc = Get-Service TermService -ErrorAction SilentlyContinue
        @($svc -and $svc.Status -eq 'Running'),
            $(if ($svc) { $svc.Status } else { 'Service missing' })
    }
    
    # Summary
    Write-Host ''
    Write-Host '=== Authyo RDP Guard pre-install self-check ===' -ForegroundColor Cyan
    $results | Format-Table Item, Status, Detail -AutoSize -Wrap
    
    $failed = ($results | Where-Object Status -eq 'FAIL').Count
    if ($failed -eq 0) {
        Write-Host "ALL CHECKS PASSED - safe to install the MSI." -ForegroundColor Green
    } else {
        Write-Host "$failed CHECK(S) FAILED - fix above before installing." -ForegroundColor Red
    }

    3. What the MSI installs#

    A single MSI: AuthyoGatekeeper-1.0.0.msi (~1.3 MB).

    Files installed#

    PathPurpose
    C:\Program Files\Authyo\Gatekeeper\Authyo.Gatekeeper.CredentialProvider.dllThe Credential Provider that adds the Authyo tile to the logon screen
    C:\Program Files\Authyo\Gatekeeper\Authyo.Gatekeeper.Bridge.dllC++/CLI shim that hosts the .NET 8 runtime inside LogonUI
    C:\Program Files\Authyo\Gatekeeper\Authyo.Gatekeeper.Core.dllManaged library — HTTP client, JWT, DPAPI, SQLite trust cache
    C:\Program Files\Authyo\Gatekeeper\Authyo.Gatekeeper.Configurator.exeWPF wizard for setting up Client ID + Secret + contacts
    C:\Program Files\Authyo\Gatekeeper\Ijwhost.dll + SQLite libs.NET 8 host + dependencies
    C:\ProgramData\Authyo\Gatekeeper\Where config.json, trust.db, and logs live after first run

    Registry entries#

    KeyPurpose
    HKLM\SOFTWARE\Classes\CLSID\{B251F0AF-6D20-4C4D-90ED-4ADE0D8256D7}COM registration of the Credential Provider
    HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Authentication\Credential Providers\{B251F0AF-...}Tells LogonUI to load the CP
    HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Authentication\Credential Provider Filters\{B251F0AF-...}Filter registration (enforces MFA for RDP)
    Plus an Add/Remove Programs entry ("Authyo RDP Guard — Konceptwise Digital Media Pvt. Ltd.") and a Start Menu shortcut to the Configurator.

    4. Install — step by step#

    4.1 Get your Client ID and Client Secret#

    Log into https://app.authyo.io → Applications → either pick an existing application or create a new one. From the application detail page, copy the Client ID and Client Secret. Keep them in a safe place — you'll paste them into the Configurator in step 4.4.

    4.2 Download the MSI#

    In the same Authyo portal, go to RDP Guard in the left menu. Click Download AuthyoGatekeeper-1.0.0.msi under the Windows card. The file is ~1.3 MB and downloads in seconds.

    4.3 Run the installer#

    Right-click the downloaded MSI → Run as administrator.
    You may see a Windows SmartScreen warning during the v1.0.0 evaluation period (we're still publishing reputation). Click More info → Run anyway to proceed.
    The installer:
    Accepts the license agreement
    Asks for an install location (default: C:\Program Files\Authyo\Gatekeeper\)
    Installs files, writes registry entries, registers the Credential Provider
    Offers to launch the Authyo RDP Guard Configurator at the end
    Keep the "Launch Configurator" checkbox ticked and click Finish.

    4.4 Configure with the Configurator#

    The Configurator window opens. It has three sections — fill them in order.

    Section 1: Authyo application credentials#

    FieldWhat goes here
    Client IDFrom step 4.1
    Client SecretFrom step 4.1. Encrypted with Windows DPAPI before being saved — it never sits on disk in plaintext.
    API endpointhttps://app.authyo.io (already pre-filled, just confirm)

    Section 2: Admin contacts (one or more)#

    This is the list of admins who receive the OTP. OTPs go to these contacts, not to the user signing in. The admin reads the code, decides whether to grant access, and shares it with the user.
    The Configurator starts with one empty row named "Primary". Fill it in, and click "+ Add another admin contact" to add more rows. Each row has:
    ColumnNotes
    NameA friendly label (e.g. "Naveen", "On-call rotation", "Backup"). Helps you remember which entry is which.
    RecipientThe email address or phone number (with country code, no + or spaces — e.g. 919876543210) where the OTP goes.
    ChannelEmail, Sms, Whatsapp, or VoiceCall. Most setups start with Email — free and reliable.
    ✕ buttonRemove this contact. The form always keeps at least one row visible.
    After you have your contacts, pick a Delivery policy:
    PolicyWhat happens on each sign-inWallet cost per sign-in
    PrimaryOnlyOTP only goes to the first contact in the list. Other rows are listed but unused (they're inactive backups you can promote later).1 OTP
    RoundRobinOTP rotates: sign-in #1 → contact[0], sign-in #2 → contact[1], etc. Wraps around. Shares the load across multiple admins. State file lives at C:\ProgramData\Authyo\Gatekeeper\rr-state and persists across reboots.1 OTP
    AllInOrderOTP goes to every contact at the same time. All admins get the same code. Any one of them can share the OTP with the user. Best for redundancy.N OTPs (N = contact count)
    Recommended starting points:
    One admin → PrimaryOnly (default)
    Small team, share the load → RoundRobin (rotates without anyone getting overwhelmed)
    Critical server, need redundancy → AllInOrder (any admin can approve, never blocked if one is unreachable)

    Section 3: Trusted-device window (optional)#

    FieldWhat goes here
    Hours (0–24)0 = always require OTP (most secure). Higher value = skip OTP for repeat sign-ins from the same IP + user within that window. Recommended 0 for production.

    Test before saving#

    Click Send test OTP first. The Configurator sends a real OTP to the first contact in your list (so you can verify your Client ID + Client Secret + network + that contact's channel are all working). You should receive an email (or SMS, etc.) within ~10 seconds. If you don't:
    Confirm your Client ID and Secret are correct
    Confirm the Authyo application has auth priority configured for that channel (Active + Priority > 0)
    Confirm the contact address is reachable (typo? wrong country code?)
    If you have multiple contacts and you're using AllInOrder or RoundRobin, the test only exercises the first contact — once it works for that one, the others use the same backend path and should also work as long as their channel has auth priority set.
    Once the test works, click Save config. You'll see:
    Saved to C:\ProgramData\Authyo\Gatekeeper\config.json. 3 contact(s), policy=AllInOrder. Lock the screen (Win+L) to see the Authyo RDP Guard tile.
    (The summary line shows how many contacts and which policy were saved — quick visual confirmation.)

    4.5 Sign in via the Authyo tile#

    Press Win + L to lock the screen.
    You should see two tiles at the bottom-left (alongside the standard user tiles):
    The standard Windows password tile for each existing user
    A new Authyo RDP Guard tile with the Authyo logo
    Click Authyo RDP Guard:
    1.
    Type your Windows username
    2.
    Type your Windows password
    3.
    Click the → arrow (Submit)
    4.
    Wait for the OTP to arrive at the configured admin contact
    5.
    Type the OTP into the new field
    6.
    Click → again
    Windows logs you in.

    4.6 Verify it's working#

    Open PowerShell as Administrator and run:
    Get-Content 'C:\ProgramData\Authyo\Gatekeeper\logs\gatekeeper.log' -Tail 10
    You should see:
    INFO   user=naveen ip=console GATE_START
    INFO   user=naveen ip=console SENDOTP_OK contact='Primary' via=Email to=nav***com maskId=...
    INFO   user=naveen ip=console JWT_VERIFIED
    INFO   user=naveen ip=console GATE_PASS
    GATE_PASS is the final success marker. If you see that line every time you sign in, Authyo RDP Guard is working correctly.

    5. Using Authyo RDP Guard with Remote Desktop#

    Install Authyo RDP Guard on the server you want to protect, not on the client machines that connect to it. When someone opens mstsc and connects, the server's logon screen renders inside the RDP window — and your Authyo tile appears there exactly like it does on the physical console.

    5.1 One-time server prep — disable NLA#

    If you skipped section 2.5.1 above:
    (Get-WmiObject -class Win32_TSGeneralSetting `
        -Namespace root\cimv2\TerminalServices `
        -Filter "TerminalName='RDP-tcp'").SetUserAuthenticationRequired(0)

    5.2 Test from a client#

    mstsc /v:your-server.example.com
    You should see the Windows logon screen in the RDP window. Pick the Authyo RDP Guard tile, enter username + password, get the OTP at your admin contact, type it in, you're in.
    RDP reconnect to a disconnected session also fires the OTP gate (Windows raises CPUS_UNLOCK_WORKSTATION, which our tile handles identically to first connect). Each reconnect = another OTP. This is the intended security behavior.
    What about an OTP prompt at the client's mstsc step (before connecting)? That's CPUS_CREDUI — a separate scenario that fires on the client side. v1.0.0 doesn't register for it; the OTP gate only runs once you reach the server's logon. This is deferred to v1.1 because it shifts the OTP from the protected server to the (potentially untrusted) client.

    6. Day-to-day usage#

    Adding or changing admin contacts#

    Re-launch Authyo RDP Guard Configurator from the Start Menu. The existing contacts are pre-loaded; add new rows with the "+ Add another admin contact" button, remove rows with the ✕ button, or change the delivery policy. Click Save config when done. Changes take effect on the next sign-in attempt — no reboot needed.

    Disabling OTP temporarily#

    If you need to skip OTP for a sign-in (incident, network outage), just delete or rename C:\ProgramData\Authyo\Gatekeeper\config.json. When the config is missing, the Authyo tile silently hides and users sign in via the standard Windows password tile. Restore the config to re-enable.

    Logs#

    FileWhat's in it
    C:\ProgramData\Authyo\Gatekeeper\logs\gatekeeper.logPlain-text log of every sign-in attempt: GATE_START, SENDOTP_OK/FAIL, JWT_VERIFIED, GATE_PASS
    Windows Event Viewer → ApplicationAnything that fails before the Authyo log is initialized — useful if the Credential Provider itself can't load
    Logs are append-only and rotate weekly; they don't grow unbounded.

    7. Troubleshooting#

    The Authyo tile doesn't appear on the lock screen#

    Most common cause: config.json is missing or corrupted.
    # Confirm the config exists and is readable
    Get-Content 'C:\ProgramData\Authyo\Gatekeeper\config.json'
    
    # Confirm the Credential Provider is registered
    $clsid = '{B251F0AF-6D20-4C4D-90ED-4ADE0D8256D7}'
    Test-Path "HKLM:\SOFTWARE\Microsoft\Windows\CurrentVersion\Authentication\Credential Providers\$clsid"
    If both are present and the tile still doesn't appear, the .NET 8 Desktop Runtime is probably not installed. Run dotnet --list-runtimes and confirm the Microsoft.WindowsDesktop.App 8.0.x entry is there.

    "OTP did not verify"#

    The OTP entered didn't match what the backend issued. Common causes:
    OTP expired (default expiry is 5 minutes)
    OTP from an earlier session — type the one from the most recent email
    The Authyo application's auth priority changed between SendOTP and VerifyOTP (rare; ask support if it persists)
    You can retry up to 5 times within the maskId's lockout budget.

    "Windows rejected the credentials"#

    The OTP verified correctly, but Windows itself didn't accept the password:
    Confirm the username matches an existing local or domain account
    Confirm the password is correct (try signing in via the standard password tile to isolate)
    If the account uses Microsoft Account (MSA) sign-in, use the MSA tile instead — the Authyo tile uses NTLM/Kerberos, not MSA tokens

    Some admins get the OTP, others don't (AllInOrder)#

    If you're using the AllInOrder policy and only some admins receive the OTP:
    Each channel needs its own auth priority configured in the Authyo application (Email priority, SMS priority, etc.)
    Check gatekeeper.log — SENDOTP_FAIL lines tell you which contact's send failed and why
    The sign-in still completes as long as at least one contact's send succeeded (the user only needs one valid OTP)

    Network errors / "Cannot reach Authyo"#

    The machine couldn't reach app.authyo.io. Confirm:
    Internet access works on the machine
    Firewall doesn't block HTTPS port 443 outbound
    DNS resolves app.authyo.io (try nslookup app.authyo.io from an admin PowerShell)
    By default, if Authyo is unreachable, sign-in is denied (fail-closed). You can change to fail-open via the policy section in config.json — not recommended for production.

    Collecting a diagnostics bundle for support#

    Compress-Archive `
        -Path 'C:\ProgramData\Authyo\Gatekeeper\logs',
              'C:\ProgramData\Authyo\Gatekeeper\config.json' `
        -DestinationPath "C:\authyo-diagnostics-$(Get-Date -Format yyyyMMdd-HHmmss).zip"
    The bundle contains the Authyo log and your config (the clientSecretEncrypted blob is DPAPI-encrypted, so it's safe to share — nobody but the machine that created it can decrypt it).
    Email the zip to support@authyo.io with a brief description of what you tried and what you observed.

    8. Common failure modes — quick reference#

    SymptomMost likely causeFirst thing to check
    MSI installs but Authyo tile doesn't appear.NET 8 Desktop Runtime missingdotnet --list-runtimes
    Tile appears but says "Cannot reach Authyo"DNS / HTTPS / firewall blocking app.authyo.ioInvoke-WebRequest https://app.authyo.io/ -UseBasicParsing
    Tile shows "auth priority not set"Authyo application missing auth priority for one of the channelsPortal → app settings → enable the channel + set priority > 0
    Some channels work, others failPer-channel auth priority — Email may be configured but SMS isn'tConfigure auth priority for every channel you list in contacts
    Email never arrivesWrong contact, rate limit, or auth priority issueCheck gatekeeper.log for SENDOTP_OK vs SENDOTP_FAIL
    OTP entered but says "OTP did not verify"Wrong code, expired (5 min), or backend lockoutWait 30s, retry; retry budget is 5 wrong before lockout
    OTP verifies but "username or password incorrect"LSA rejected the Windows passwordTry same credentials on the standard Windows password tile
    RDP signs in WITHOUT OTPNLA is enabled — pre-authenticates before Authyo loadsDisable NLA — section 2.5.1
    RDP shows the tile but stuck at logonNetwork kill during OTP step + blockOnAuthyoUnreachable=trueCheck gatekeeper.log; resolve network; or temporarily set blockOnAuthyoUnreachable=false
    Tile gone after install, no Authyo in Add/RemoveDPAPI machine key rotated; config.json undecryptableRe-run Configurator and re-save
    Wallet drains fastAllInOrder policy with many contacts × frequent sign-insSwitch to PrimaryOnly or RoundRobin if cost is a concern
    Customer locked out, no rescue adminWorst case — needs console / safe-mode bootSee Disaster recovery below

    9. Disaster recovery — when nobody can sign in#

    1.
    Try a different local admin via "Other user" on the lock screen.
    2.
    Safe Mode boot — Authyo CP doesn't load in Safe Mode. Hold Shift + Restart, or power-cycle 3 times to force Recovery Environment. Sign in as any local admin → Settings → Apps → Authyo RDP Guard → Uninstall.
    3.
    Boot from Windows install media → Repair → Command Prompt → reg delete HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Authentication\Credential Providers\{B251F0AF-6D20-4C4D-90ED-4ADE0D8256D7} /f → reboot. (Wipes the CP registration; reinstall when ready.)
    4.
    Contact support@authyo.io for emergency assistance.

    10. Uninstall#

    Settings → Apps → Installed apps → Authyo RDP Guard → Uninstall.
    Or from an elevated PowerShell:
    $app = Get-WmiObject Win32_Product -Filter "Name='Authyo RDP Guard'"
    $app.Uninstall()
    The uninstaller removes all Authyo DLLs from C:\Program Files\Authyo\Gatekeeper\, all four registry entries, the Start Menu shortcut, and the Add/Remove Programs entry.
    The uninstaller does not remove C:\ProgramData\Authyo\Gatekeeper\ (your config.json and trust.db). For a full purge:
    Remove-Item 'C:\ProgramData\Authyo' -Recurse -Force
    If NLA was disabled for RDP Guard, re-enable it:
    (Get-WmiObject -class Win32_TSGeneralSetting `
        -Namespace root\cimv2\TerminalServices `
        -Filter "TerminalName='RDP-tcp'").SetUserAuthenticationRequired(1)
    After uninstall, the next Win+L will show only the standard Windows password tile. No reboot required.

    11. Security notes#

    Client Secret on disk: encrypted with Windows DPAPI machine-scope. Only the local SYSTEM context (which LogonUI runs as) can decrypt. The blob is useless if exfiltrated to another machine.
    OTP transport: HTTPS to app.authyo.io, TLS 1.2+, server-cert validated by the default Windows trust store.
    JWT verification: every OTP verify response carries a JWT signed with HMAC-SHA256 using your Client Secret. Authyo RDP Guard validates the signature locally — a forged "success" response without a valid JWT is rejected even if the HTTP body says success: true.
    Trust device cache: trust.db is a SQLite file storing source-IP + username fingerprints (no passwords, no tokens). Bounded TTL, defaults to 0 (always require OTP).
    No bypass of Windows auth: Authyo RDP Guard layers OTP on top of the standard Windows logon. A successful OTP plus a wrong Windows password still gets rejected by LSA. RDP Guard never substitutes for Windows credential validation.
    Multi-contact delivery: when using AllInOrder, every contact gets the same OTP (same maskId), so any one admin can share the code. This is delivery redundancy, not multi-party approval.

    12. Support#

    Email: support@authyo.io
    Portal: https://app.authyo.io
    License: Proprietary (the Windows Credential Provider). See LICENSE in the install directory.
    Copyright 2026 Konceptwise Digital Media Pvt. Ltd.
    Modified at 2026-05-22 10:28:00
    Previous
    About Pricing
    Next
    Send OTP
    Built with