How PWF Auth works: licence keys, HWID lock and a live kill switch

You sell a program. A customer pays and gets a key, and from that moment you want three things: the key works on their PC only, you can stop it whenever you need to, and nobody can fake the server's answer. This article explains how PWF Auth does each of them, in plain words, so you can answer your customers and set the right expectations

Signing in opens a session

When a customer types their key, your program sends it to PWF Auth together with the PC's hardware ID (HWID). If the key is valid, the server answers with the licence details and opens a session: one running copy of your program on one PC

Every session shows live in Sessions in your panel, with the PC it runs on, so you always know who is using your program right now

The heartbeat: a check-in every 30 seconds

While the program runs, the SDK asks the server every 30 seconds whether the session is still good. That question is the heartbeat, and every answer re-checks everything: is the key banned, paused, expired or deleted, was its machine reset, is the app in maintenance?

Your customers sit behind home routers, so the server cannot reach their PC on its own. It waits for the next heartbeat to deliver bad news, which is why a ban takes up to 30 seconds:

• You ban, pause or delete a key: the program closes on its next check-in and shows BANNED, PAUSED or that the licence no longer exists
• You end a session in Sessions: the customer reads that the developer ended the session, and can sign in again
• You reset the key's machines: the program closes and says the hardware ID was reset
• The key reaches its expiry date: the program closes with EXPIRED

No internet is not a way around it

If three heartbeats in a row get no answer (about 90 seconds), the SDK ends the session itself with NETWORK_LOST. Without this rule, blocking PWF Auth in a firewall would keep a banned copy running forever. In Sessions, a copy that stays silent for five minutes shows as Timed out

One key, one PC

The first sign-in binds the key to that PC. On any other PC it is refused with HWID_MISMATCH, and a key you allowed on several PCs refuses the next one with DEVICE_LIMIT. That is what stops one paid key from being shared in a group chat

Customers do change PCs. They can move their licence by themselves when you allow it, or ask you to reset it: see HWID resets

Encrypted and signed

Every sign-in, heartbeat and content request is encrypted with AES-256 and signed with HMAC-SHA256, using two keys made from your app secret. Each message carries a timestamp, and the server refuses one that is more than five minutes off, so a recorded request cannot be played back later

The server signs every reply too, and an answer that is not encrypted and signed is never trusted as a success: the SDK treats it like no answer at all. A fake "key is valid" server has nothing to offer

Free trials

Switch trials on for an application and a new PC can get a trial key with one call, without buying. Each PC gets one trial, and you choose its length on the application

Try it

PWF Auth is free. Create an account, then follow Getting started: six steps from a new account to a protected app. Official SDKs cover C# and VB.NET (NuGet), Python (PyPI) and C++, and the SDK generator in the panel writes a ready client file for JavaScript, Java, Kotlin, PHP, Dart, Delphi and more

The full details, with every error code, are in How protection works