V

VigilMFA

Vigil / 2026

Clerk × Supabase

A passwordless MFA console where every verified state change is written to an append-only ledger.

Create your console

01 / Premise

Most MFA demos stop at the QR code. The interesting part starts after the first code is accepted.

A password is a promise.
A second factor is proof.

Vigil treats enrollment as a state change worth recording: who enabled what, when the server last checked, and whether Clerk and the ledger agree. The UI is quiet. The record is not.

02 / The menu

Six controls, one rule: nothing reaches the record until the server verifies it.

Vigil / security menuEst. 2026

What the console does.

A small, deliberate surface. Every item is included; none of them stores a secret in this application.

Entry

Passwordless entryemail code

No password to reuse. Clerk sends a six-digit code to the verified address.

Session gatealways

The dashboard will not open until a verified second factor exists.

Second factor

Authenticator appTOTP / 30s

Scan once. Verify one rotating code. The secret stays inside Clerk.

Backup codes10 / single-use

Generated once, shown once, and replaced whenever a new set is made.

Evidence

Server verificationper event

The API re-reads the user from Clerk before it writes a single row.

Audit ledgerappend-only

Supabase Postgres with RLS on. Service-role writes only, no browser key.

Session reviewper device

See active sessions and revoke the ones you do not recognise.

No password storedNo TOTP secret stored

03 / Sequence

Four movements. No shortcut through the second one.

  1. 01 / First

    First, prove the inbox.

    Enter your email. Clerk sends a six-digit code to the verified address. Nothing else is asked for.

  2. 02 / Then

    Then, open the authenticator.

    Scan the QR code once. Type the rotating six-digit code to prove the secret landed on your device.

  3. 03 / Now

    Now, the session is gated.

    Without a verified second factor, the console routes back to setup. There is no skip control.

  4. 04 / Finally

    Finally, leave a record.

    The server re-reads your MFA state from Clerk, then writes the verified snapshot to Supabase.

A modern fingerprint scanner for secure access control

04 / The physical layer

Small habit.
Permanent record.

A fingerprint scanner is not a TOTP code. The analogy is the point: a second factor should be a physical act, not another password.

Photo: panumas nikhomkhai / PexelsVigil / 04

05 / The record

Built by people.
Checked by machines.

Vigil is a deliberate second experiment. The first build used Better Auth, Turso and Resend. This one moves identity to Clerk and the audit trail to Supabase. Same brief, different architecture.

Read the source
Build01

Indeep Kour

Product direction, interface, original MFA experiment

Pair02

IBM Bob

Implementation partner: code, review, documentation

ibm.com/bob
Identity03

Clerk

Email code, TOTP, backup codes, session policy

clerk.com
Ledger04

Supabase

Postgres audit trail, RLS, server-only writes

supabase.com
Photography05

Pexels

Six credited images, downloaded locally

pexels.com
Source06

GitHub

Public repository, setup notes, deployment path

Repository

The original build lives in a separate repository and keeps its Better Auth + Turso + Resend stack. Vigil is not a migration of that code; it is a second answer to the same brief.

Two builds / one brief

06 / Questions

Worth asking.

The honest version of each answer, including what is deliberately left out of this build.

01Does Vigil store my authenticator secret?
No. TOTP secrets and backup codes live inside Clerk. The Supabase ledger stores the verified boolean state — whether TOTP or backup codes were enabled at the moment the server checked — not the secret itself.
02What exactly is in the audit log?
A Clerk user ID, the event type, whether TOTP and backup codes were enabled, the session ID when relevant, the source of the event, and a timestamp. No codes, no secrets, no email body, and no free-form client text.
03Can I run the console without a Supabase project?
Yes. Authentication, enrollment, recovery codes and session review all work. The activity page shows a clear “ledger not connected” state instead of failing silently. Add the Supabase URL and service-role key to switch it on.
04Why Clerk and Supabase instead of Better Auth and Turso?
Clerk handles the MFA factors, recovery and session policy as a managed identity layer. Supabase gives the application a Postgres ledger that is deliberately separate from identity. The separation is the point of this build.
05Is MFA enforced by the app or by Clerk?
Both, at different layers. Clerk enforces the second factor during sign-in. The dashboard layout redirects users who have not enrolled to the setup screen. That redirect is UX; the security boundary is Clerk.
06What happens if I lose my authenticator?
Use one of the single-use backup codes. If both the authenticator and the codes are gone, an instance administrator has to reset the user's MFA in the Clerk dashboard. There is no self-service bypass.
07Is this a production-ready compliance product?
No. It is a working, documented demo. For production, claim the Clerk application, move to a plan that includes MFA, configure the Clerk webhook, set the service-role key in your host, review the RLS policy, and add your own monitoring.

07 / The gate

Vigil

Are you

Create your consoleorRead the build

Email code first. Authenticator second. The whole verified state on the record.

who you say?