About a year and a half ago, we signed CISA’s Secure by Design pledge. Seven goals, twelve months, and a public commitment to show measurable progress on all of them.
This is the follow-up post. It’s the one where we tell you what actually happened, including the part where we initially missed a target by a mile.
Here’s the short version: we went from 4% of our users having MFA enabled to 100% of accounts authenticating with a second factor. But we didn’t get there the way we planned, and the two attempts in between are more interesting than the result.
Why we only picked one pillar
The pledge has seven goals. We deliberately didn’t spread ourselves across all seven.
When we scored ourselves honestly at the start, most of them were either already met or didn’t really apply to us. We’ve had a published vulnerability disclosure policy for years, plus a running bug bounty program. We have no default passwords in the product, and we committed to never introducing any. We’re pure SaaS, so there are no patches for customers to install. Our customer-facing audit log had already shipped, with RBAC and notifications following behind it. CVEs are rare for a company like ours, so we wrote the policy and moved on.
That left one pillar with a real, embarrassing, measurable gap.
4% of our active users had MFA enabled.
For context: consumer SaaS benchmarks sit somewhere around 10–30%. Business SaaS is more like 30–50%. We were at 4%, and we’re a backup company. We hold the copy of last resort for 25,000+ organizations, 7.4 petabytes of data, and 154 billion files across 15+ platforms including GitHub, Jira, Confluence and Shopify.
That makes our account security a bit unusual. A single compromised login at Rewind doesn’t expose one record — it exposes a customer’s entire history. Authentication isn’t a supporting feature for us. It’s the product surface.
So: one pillar, measured properly. That beats seven claims.
Getting it resourced (the unglamorous part)
Nobody hands you a budget for signing a pledge. This work was competing directly with revenue work, which is a fight security work usually loses.
Three things made the difference:
We put it on the corporate risk register. Not as an engineering wish, as a formal corporate risk with a named owner and a required mitigation. That puts it in front of the exec team every single review cycle. A KPI gets you reported on. A registered risk gets you prioritized.
We put both MFA KPIs on the corporate scorecard. Reported monthly, alongside revenue metrics, in the same review and the same format. Security targets that live in a security doc get read by security people only.
The pledge itself was leverage. It’s a signed, public commitment. That reframes the work from something we intend to do into something we’ve already said we would do. Turns out that’s a meaningfully different conversation.
Two KPIs, set before we started
We picked our measures up front, which I’d recommend to anyone doing this:
| KPI | Baseline | Target |
|---|---|---|
| % of active users with MFA enabled | 4% | 40% |
| Organizations with “Enforce MFA” turned on | 0 | 100 |
One measures user behaviour. One measures administrator behaviour. Remember that distinction, because it turned out to be the whole story.
What we built
No single change was going to close a 36-point gap, so we picked the two changes with the best effort-to-lift ratio.
Org-level enforcement (shipped). We gave organization owners a switch that requires MFA for every user in their org, the way GitHub does. As we move upmarket, larger customers want more granular control over the users they administer — and most of them already carry an MFA requirement from their own compliance program. Their requirement, our adoption number. Mutually beneficial.
Nudges and reminders (shipped). In-app banners. A periodic login interstitial citing Microsoft’s finding that MFA blocks over 99% of account compromise attacks. Deep links straight to the security settings page. A line in the weekly admin summary email showing how many users in the org still didn’t have MFA on.
We also considered and rejected two other options:
Incentives (rejected). Free backup credit for enabling MFA. We passed. Paying customers to adopt a baseline control is very hard to unwind later, and it frames security as optional.
Mandatory MFA (deferred). We looked at this at the start and set it aside over signup friction and conversion fears. We came back to it. This will return later in this post.
Results after one year
One clear miss. One clear win.
% of users with MFA: 4% → 6.4%. Target was 40%. We hit 16% of it.
Orgs enforcing MFA: 0 → 179. Target was 100. We hit 179% of it.
The 179 is the part I still find remarkable. It arrived with no announcement, no campaign, and no email. Admins saw the button ship and turned it on themselves.
What we learned
Asking users nicely does not work. All the nudges shipped. All of them landed. They moved the value 2.4 points. An end user has no personal incentive to add friction to their own login, and better copy doesn’t change that. We were optimizing the wrong actor.
Admins had the leverage. One owner flipping one switch protects an entire organization. We never even advertised the feature.
Defaults beat persuasion. Every point of progress we made came from changing what happens by default, not from convincing someone to act. That conclusion is what took us to the mandate.
The thing that ended the debate
In November 2025, we saw unauthorized access to a customer account. They were reusing a password from elsewhere. Their account had no MFA enabled.
It didn’t change our direction — we’d already worked out where the data was pointing. What it did was end the internal discussion about whether a mandate was worth the friction.
Mandatory MFA: a floor, not a wall
We shipped mandatory MFA on 1 June 2026. The design goal was to remove the objection that had stalled it for a year.
- Signup untouched. No new steps, no new fields. Conversion was the blocker, so we took it out of the equation entirely.
- Told at welcome. The welcome email states that MFA is required, explains why, lists the available options, and links straight to enrollment.
- Emailed one-time code as the floor. Not enrolled in a stronger factor? Every login sends a one-time code to your email that you have to enter. No account sits without a second factor.
- Upgrade at will. Users can move to TOTP or WebAuthn whenever they like. The floor is mandatory; the ceiling is theirs.
The industry moved on emailed codes over the course of our pledge year, which is what made this viable without touching conversion. A one-time code in your inbox went from novel to expected and in fact, the default for many consumer apps and web sites now.
It shipped alongside three other pieces of authentication hardening: re-verification for dormant accounts after 90 days of inactivity, long-window rate limiting (short-term limits are easy to stay underneath if you’re patient), and geolocation login alerts for the impossible-traveller case.
Credit where it’s due — Jason Meredith did the implementation work on all of this.
Where we are now
100% of Rewind accounts now authenticate with a second factor. There is no path to a session without one.
- No reported issues since shipping the feature in June 2026
- No customer pushback on the mandate that we’ve heard of
- 296 organizations (as of July 2026) still enforcing above the floor
We spent a year fearing friction that never showed up.
What we’d tell another signatory
One pillar, measured honestly. Depth on one pillar produces a story worth reading. Seven claimed pillars produce a press release.
Target the actor with the switch. Our end-user KPI missed by a mile. Our administrator KPI beat the target by 79%. Same effort, different actor.
Ship nudges, but don’t bet on them. They’re cheap and they do no harm. They will not carry a 36-point adoption target.
The mandate is cheaper than you think. Given the year over again, we’d have mandated it in month two.
One other thing that shipped
Worth a quick mention, because it was a commitment in the original post: we said we’d let customers pipe Rewind’s security alerts into their existing tooling, and that shipped as External Notifications. Admins can route specific event categories — security events being their own category — to recipients who don’t have a Rewind account, including monitoring platforms. Evidence of intrusion isn’t much use sitting in a UI nobody’s watching.
What’s next
Next pillar: reducing entire classes of vulnerability.
We ranked every submission to our bug bounty program by vulnerability class, and MFA bypass came out first. So that’s where we’re starting — picked from our own data, not from a list of things that sound important.
Our shared authentication code has accumulated real complexity over the years. Jason has already begun refactoring it, and that work continues. Same playbook as last time: pick the class our data says is the worst, fix the code that produces it, and put a number on it.
You can follow our pledge progress and security reporting at security.rewind.com.
At Rewind, security isn’t just a responsibility — it’s a promise. And a year on, we’d rather tell you about the wins and losses than the ones we quietly redefined.
Dave North">
