Multi-Factor Authentication in RaptorGRC: What Ships and What Is Enforced

Illustration for: Multi-Factor Authentication in RaptorGRC: What Ships and What Is Enforced

Biff Labs signed CISA’s Secure by Design pledge in August 2026. The first of its seven goals asks a manufacturer to “demonstrate actions taken to measurably increase the use of multi-factor authentication across the manufacturer’s products”. This article is the engineering answer for RaptorGRC. What authentication exists in the code, who controls it, and the one default we have not yet changed.

I am going to be specific about that last part, because the interesting half of any pledge write-up is the half that admits what has not happened.

Two systems are in scope and they are not equally far along

There are two pieces of software here and it matters which one a claim is about.

The customer portal at raptorgrc.com is where you register, activate a licence and download releases. We run it, and we can change its behaviour for everyone overnight.

RaptorGRC itself is a container that runs inside your network, often with no route to the internet at all. We cannot change a running deployment. Everything we do there is a change to what the next version ships with, and it reaches you only when you choose to pull it.

Treating those two as one product would flatter the answer, so the rest of this article keeps them apart.

What the portal enforces today

Every account has a second factor

Every account on the portal, customer and staff alike, has two-factor authentication switched on. It is not a user preference and there is no screen to turn it off.

New accounts get the flag at creation. A data migration in August 2026 switched the flag on for every account that already existed, because a rule that applies only to people who signed up after it was written is not a rule.

The default factor is an emailed code

The out-of-the-box second factor is a six-digit code sent to the registered address, valid for one use, with only the newest code accepted.

Anyone who would rather not depend on email can enrol an authenticator app instead. Scan the code, confirm one value, and the account is issued ten single-use recovery codes for the day the phone is lost. Re-enrolling rotates those codes, so an old printout stops working rather than quietly remaining valid.

Two weaknesses worth naming

The sign-in screen offers to trust a browser for thirty days, which suppresses the second factor on that browser for that period. It is a deliberate trade, because the alternative is people looking for ways to switch the whole thing off, but it is still a weakening and thirty days is longer than the framework default of fourteen.

Portal passwords require eight characters with the standard complexity rules, and an account locks after five failed attempts. Eight is short. The product asks for ten, and the portal should match it.

What the product ships

RaptorGRC supports time-based one-time passwords, the ordinary authenticator-app factor. Enrolment and challenge are built into the product rather than delegated to an add-on, so a user enrols from their own settings page and is challenged at the next sign-in.

More useful to an enterprise is the deployment-wide policy an administrator sets from the sign-in security screen. It has four positions, which are off, optional, required for administrators, and required for everyone.

When enforcement is switched on, users who have not yet enrolled get a small number of grace sign-ins before they are pushed into enrolment. That exists so a policy change on a Friday does not lock out the whole finance team on Monday. The moment a user is forced into enrolment is written to the audit log, so the change is visible afterwards.

RaptorGRC also supports standards-based single sign-on over OIDC and SAML, plus LDAP and Active Directory authentication. CISA lists baseline SSO support as an approach to this goal in its own right, because it lets a customer bring their own identity provider and their own factors. Ours is in the baseline product at no extra cost, which is an easy thing for us to say given there is one edition and it is free.

What we have not built

Enforcement is not the default

A fresh RaptorGRC deployment starts with the MFA policy set to optional. An administrator has to go and change it.

That is the gap our pledge page has listed as in flight since the day we signed, and it is still open. CISA’s first listed example approach for this goal is enabling MFA by default for users and administrators. We have built the mechanism and we have not flipped the switch, so on a strict reading we are part way there and not further.

There is no phishing-resistant factor anywhere

Neither system supports WebAuthn, passkeys or hardware security keys. Emailed codes and authenticator codes are both phishable, and a convincing sign-in page will harvest either one.

CISA’s wording points specifically at phishing-resistant MFA as the more valuable form. We do not have it, in the portal or in the product, and no amount of enrolment in the factors we do have closes that particular gap.

The product has no recovery codes

If a user in a RaptorGRC deployment loses their authenticator, an administrator has to intervene. The portal issues recovery codes and the product does not. That is a small thing until enforcement is on, at which point it becomes the reason an administrator turns enforcement off again.

Single sign-on sessions bypass the policy

When a user signs in through SSO, the deployment’s MFA policy does not apply to that session. The identity provider owns the factor at that point, and stacking a second RaptorGRC challenge on top of an enterprise challenge is friction with very little security in it.

My own view is that this is the right design. It is also a fact that “required for everyone” does not literally mean every session, and you should know that before you rely on the setting to satisfy an auditor.

Why there are no adoption statistics in this article

CISA suggests demonstrating progress on this goal by publishing aggregate MFA adoption over time, broken down by user type and factor. We cannot produce that, and we never will while the product works the way it does.

RaptorGRC runs inside your network and does not phone home. There is no telemetry, no check-in and nothing that reports who enrolled in what. The only thing that ever reaches us is the usage summary carried in an offline activation request, which contains counts of records and users and says nothing at all about authentication. That summary is published in full, unedited, on our transparency page.

The pledge anticipates this. Its own note on goal one accepts progress shown “either through results of customer behavior, or through changes to the product itself”. Ours has to be the second kind.

This cuts both ways and I would rather it did. We cannot measure your adoption. We also cannot quietly collect it.

The case for leaving the default alone, taken seriously

There is a real argument against enforcing MFA out of the box in a self-hosted product, and it deserves better than a strawman.

A RaptorGRC deployment is frequently air-gapped. On an isolated network there is no route for an outside attacker to reach the sign-in page at all, and the compensating controls sit at the network boundary rather than in the application. Forcing every user through authenticator enrolment on a system with no internet access adds real operational cost against a threat the network design has already addressed. Enrolment also assumes each user has a device that can run an authenticator, which is not a safe assumption in a secure facility where personal phones are left at the door.

That argument holds for genuinely isolated deployments. It does not hold for the many deployments that sit on an ordinary corporate network, and it is not a reason for the default to favour the weaker configuration. The better answer, in my view, is a default that requires a second factor for administrators, with a documented and deliberate way for an isolated site to relax it and a record in the audit log when someone does.

Where this goes next

The change that would matter most is making enforcement the default for local accounts in new deployments, with SSO-only deployments unaffected. After that, phishing-resistant authentication in both the portal and the product, and recovery codes in the product so enforcement does not simply generate a support queue.

None of those have dates and I am not going to invent any. That ordering is my recommendation, not a commitment. When one ships, this article and the goal one entry on the pledge page change together, because a progress page that quietly drifts out of date is worse than no progress page at all.

The full tracker is at /secure-by-design. What does and does not leave your network is set out at /transparency.