MFA · ProofFlow

Don’t approve “someone signing in”. Approve this operation.

ProofFlow is AuthGuard’s MFA for what matters. The confirmation is bound to the exact operation the person sees, given with a passkey or on the phone with the comparison code, decided once and kept in a signed receipt you can verify offline. For everyday sign-in, passkeys, phone approval, TOTP and HOTP cover the browser, Windows and the VPN.

See ProofFlow in a demo See how it works

Canonical request · SHA-256
Comparison code
Decided once
Signed receipt

ProofFlow · requestillustrative example

Operation: Pay invoice INV-42
Amount: €1,250.00
Destination: PT50 •••• •••• 4417
Requested by: Finance ERP
SHA-256 digest: 9f3c 51a0 … 7be2 e21a

Comparison code 205 731 the same code on the screen and on the phone

Signed receiptML-DSA-65 (+ Ed25519 in hybrid mode) · verifiable offline

Canonical request
Code compared
Decided once
Signed receipt

Watch

Approve this operation.

Narrated in English, with English and Portuguese subtitles. Real product screens; people, organisations and amounts are fictitious.

ProofFlow · how it works

Proof that stays with the operation.

AuthGuard’s own technology, used in the console, for application sign-in, for privileged access and for requests from your other systems.

01 · Canonical request
Pin down what is being approved

The server writes the request in a canonical form with the operation, its fields and its deadline. A SHA-256 digest covers the whole request.
02 · Comparison code
The same code on both screens

The six digits are derived from the digest. On the phone, the person types the code the screen shows; three wrong codes decline the request. If the request is swapped, the codes no longer match.
03 · Confirmation
Passkey or phone

The passkey signs that digest and nothing else. Phone approval is confirmed with biometrics or a PIN.
04 · Once, with a receipt
Decided once, provable for good

In the console, the authorisation expires after two minutes and is consumed only once, with the policy evaluated again at that moment. The decision goes into a receipt signed with ML-DSA-65, plus Ed25519 in hybrid mode.

Common MFA vs ProofFlow

Approving a sign-in is not approving an operation.

The generic push-MFA pattern confirms that someone is signing in. ProofFlow confirms what is about to happen, and leaves proof.

Criterion	Common MFA (push notification)	ProofFlow
What the person sees	A notice that someone is signing in, sometimes with the application and location.	The operation. In the console, every field: amount, destination, reference. On the phone, the operation, who requested it and the reference.
What the approval is bound to	The session that is signing in.	The canonical request and its SHA-256 digest. A confirmation given to another request does not count.
Phishing and approval fatigue	A plain yes/no can be accepted out of fatigue; number matching reduces that risk.	With a passkey, it resists phishing. On the phone, the person types the six-digit code from the screen, and three mistakes decline the request.
Proof afterwards	Usually a sign-in log entry at the provider.	A receipt signed with ML-DSA-65 (plus Ed25519 in hybrid mode), verifiable outside the service with the installation’s public keys.
Where it is used	Mostly at sign-in.	Application sign-in, payments, access changes, administrative actions and requests from other systems through the intents API.

Compared with the generic push-MFA pattern; each product implements it in its own way.

Illustrative example

One person, several doors, the same app.

Marta starts her Windows laptop: she types her password and, on her phone, the number the screen shows. Mid-morning she starts the VPN and approves Connect to Lisbon VPN.

In the afternoon, the ERP asks her to approve paying invoice INV-42. She checks the amount and destination in the console, confirms with her passkey, and the ERP receives a signed receipt before it pays.

The other factors

The right factor at every door.

ProofFlow

Critical actions

People see the operation and its values
Passkey or phone with a code
A signed receipt, verifiable outside the service

See details: Critical actions

Passkeys

Phishing-resistant

Windows Hello, a phone or a FIDO2 key with a PIN
The policy can require a passkey per application
Two passkeys per person recommended

See details: Passkeys

Phone

Approval with a comparison code

Approver app for Android 14 or later
Code typed or compared, depending on the request
Three wrong codes decline the request
Phone linked with a QR code

Codes

TOTP, HOTP and recovery

TOTP authenticator apps
HOTP and OCRA tokens
Recovery codes and an email link
No SMS or voice calls

Windows

Sign-in, unlock and remote

A number on screen, approved on the phone
Offline mode with per-computer codes
Roll-out through GPO or Intune

See details: Windows

VPN and Wi-Fi

RADIUS and RadSec

Code or phone approval
The same rejection for any error
Every decision in the audit log

See details: VPN and Wi-Fi

Worth knowing

Phone approval is available on Android 14 or later only. On an iPhone, use a passkey.
In compare mode, where the person only confirms that the code matches, there is no protection against approvals given out of fatigue. Use it only when the person cannot see the code.
For requests from other systems, the requesting system must display the comparison code, and it carries out the operation after verifying the receipt.
There are no SMS or voice-call codes.
Phone approval does not work on an organisation’s custom domains; use a passkey there.
Only the passkey is phishing-resistant. Phone approval with a code is multi-factor, but it does not stop a site relaying in real time.

In the help centre

Pilot

Choose one critical operation.

A payment, an access change or an administrative task with ProofFlow, and passkeys or phone approval for the rest of the team. We define the policy and the recovery path with you.

geral@authguard.pt