Multi-factor authentication
on every workspace
Every SecPortal user can enrol a TOTP authenticator, and every workspace owner can require it for the whole team. The middleware promotes sessions to AAL2 and blocks any other route until the second factor is in place.
No credit card required. Free plan available forever.
Two factors on every account, by every member, on every workspace
Penetration testing and security consulting workspaces are some of the highest-value targets on the internet. They hold the findings, the evidence, the screenshots, and the credentials for every client a delivery firm is currently working with. A single password on its own is not an acceptable lock for that data, and a buyer evaluating SecPortal for procurement should expect every login to be protected by something the user actually has, not just something the user can be phished into typing.
SecPortal builds multi-factor authentication on top of TOTP, the time-based one-time password standard (RFC 6238) supported by every mainstream authenticator app and hardware key. Every member can enrol a factor at any time, and every workspace owner can require it for the whole team in a single click. The middleware promotes the session to AAL2 on successful verification and uses the same check across the consultant dashboard, the branded client portal, and the API surface, so there is no back door around the second factor.
How TOTP enrolment works
TOTP authenticator apps
SecPortal uses standard time-based one-time password tokens, the same RFC 6238 mechanism Google Authenticator, 1Password, Authy, Microsoft Authenticator, and YubiKey Authenticator implement. Members scan a QR code on first login or copy the secret manually if their authenticator does not support QR scanning.
Six-digit verification codes
After scanning the QR code, members enter the current six-digit token to complete enrolment. SecPortal verifies the factor through Supabase Auth and stores only the verified factor reference; the shared secret is held server-side and never shipped back to the browser after enrolment.
One verified factor per account
Each user holds a single verified TOTP factor at a time. Unverified or stale factors are removed automatically when a new enrolment starts, so a half-finished enrolment from a previous device cannot block a member from logging in cleanly.
Workspace-enforced MFA
Personal MFA is good. Workspace MFA is the policy a security firm actually wants. SecPortal lets the owner of a workspace flip a single mfa_required setting that promotes the policy to a hard requirement for every member of that workspace, regardless of whether they previously opted in. The check is enforced in middleware, on every request, on every domain.
- Workspace owners on Pro and Team plans flip a single mfa_required toggle in Settings to require MFA across the whole team
- Members without a verified factor are redirected to /auth/mfa/setup on the next request and held there until enrolment completes
- Members with a verified factor but an aal1 session are sent to /auth/mfa/verify before any dashboard or portal route renders
- Sessions are promoted to AAL2 once the verification code is accepted, and stay AAL2 until the session expires or the user signs out
- API routes, dashboard routes, settings routes, and tenant subdomains all use the same middleware check, so the gate cannot be bypassed by switching surfaces
- Personal MFA enrolment is available to every user on every plan, even when the workspace policy does not require it
The enrolment lifecycle
From a workspace where MFA is off to one where every member is at AAL2, the path is four steps. Most members finish enrolment in under two minutes once the workspace setting is on.
Owner toggles workspace MFA
In Workspace Settings, the owner enables Require MFA for all members. The PATCH writes to mfa_required on the workspace row and returns success only when the call succeeds, so the toggle never displays a stale state.
Members enrol on next login
On the next request, the middleware sees a member with no verified TOTP factor and redirects them to /auth/mfa/setup. The setup page enrols a fresh factor, displays the QR code and recovery secret, and waits for the first valid six-digit code.
Verify and promote to AAL2
When the code is accepted, Supabase Auth marks the factor verified and promotes the session from aal1 to aal2. The middleware re-checks the assurance level on the next request and lets the member through to the dashboard.
Subsequent logins use the verify step
On every later sign-in, the user enters their email and password as usual, then the verify page asks for a fresh six-digit code from the authenticator before the session is promoted to AAL2.
Why MFA matters for security delivery teams
Pentest firms and security consultants hold the most sensitive data in their clients' world: live findings, exploitation evidence, working credentials for in-scope systems, and unredacted screenshots. The cost of a single account takeover on a workspace like that is the cost of every active engagement combined. MFA is the single highest-leverage control a small team can add to push that probability down, and most enterprise procurement questionnaires now treat its absence as a hard fail when evaluating a testing provider.
- Pentest and consulting workspaces hold findings, scan results, screenshots, and credentials that are highly attractive to attackers and competitors
- Stolen passwords are one of the most common initial-access vectors recorded in published incident response data, and a TOTP factor breaks that path on its own
- ISO 27001 Annex A 8.5, SOC 2 CC6.1, NIST 800-53 IA-2, PCI DSS 8.4, and Cyber Essentials all expect multi-factor authentication on administrative and remote access
- Workspace MFA gives the buyer a defensible answer when their own client asks how the security firm protects access to their data
- Audit-trail events recorded through the activity log become more meaningful when every actor row is tied to an AAL2 session
Built-in guardrails
MFA is only as good as the corner cases. SecPortal handles the forgettable ones (half-finished enrolments, lost devices, mid-session AAL changes) by checking the assurance level and the workspace policy on every request and steering the user back to the right step until they are at AAL2.
- AAL2 enforcement runs in middleware, before any route handler executes, so a forgotten check inside a page cannot leak data to an aal1 session
- The middleware skips the MFA pages themselves and the auth callback route, so a user who enrols can complete the flow even when MFA is required workspace-wide
- Half-enrolled factors are unenrolled automatically the next time the member visits /auth/mfa/setup, so a discarded device cannot leave the account in an unusable state
- Workspace owners cannot disable MFA for individual members, only for the whole workspace, so a single weak link cannot be carved out without re-evaluating the policy
- The login flow checks both the personal MFA factor list and the workspace mfa_required flag, so a member can opt in to MFA for their own account even when the workspace does not require it
How MFA fits with the rest of the platform
Workspace MFA pairs with the other access controls in SecPortal: team management provides per-role permissions through five team roles (owner, admin, member, billing, and viewer), and compliance tracking lets the owner map the MFA control to the relevant audit clauses in ISO 27001 and SOC 2. If the workspace also serves clients through tenant subdomains, the same AAL2 enforcement runs against the portal session, so a client viewer account is held to the same authentication standard as the consultant who delivered the report. For a deeper view of how access controls fit together in an end-to-end security delivery workflow, see the long-form guide on the pentest project management workflow.
Related use cases
Turn on MFA in two minutes
Owners enable workspace MFA from Settings, members enrol an authenticator app on next login, and every session is promoted to AAL2 from then on.
No credit card required. Free plan available forever.