Butterfly Security is now in the Okta Integration Network

Today the Butterfly Security app is live in the Okta Integration Network.

If you administer Okta, you can search the OIN catalog for "Butterfly Security," click Add Integration, and connect your team's identity directory to Butterfly's backup and disaster-recovery platform without writing a line of glue code. Single sign-on with OIDC. SCIM 2.0 provisioning. Role-based entitlements. All from one listing.

What's in the box

The integration ships with three things, in this order of how often you'll touch them.

Single sign-on (OIDC). Your team signs into Butterfly Security through Okta. We do domain-based detection at the login page — anyone with an email address on a domain you've configured for SSO is redirected to your Okta authorization server automatically. First-time sign-ins are provisioned just-in-time at the read-only role, which keeps the surface area small until you decide otherwise.

SCIM 2.0 provisioning. Add a user to the Butterfly app in Okta and they appear in Butterfly with the right role. Update them in Okta and the change syncs. Unassign them and they're deactivated. The integration uses standard SCIM 2.0 with bearer-token authentication — Okta auto-prefixes the "Bearer" header, so you paste the raw token and you're done.

Role-based entitlements. Butterfly's five roles — super_admin, admin, backup_operator, auditor, read_only — are exposed as SCIM entitlements. If you're using Okta Identity Governance, you can assign these via access requests, certifications, or automated provisioning policies. If you're not, you can still set roles directly via the SCIM payload.

Why this took a while

We started this work last year. The temptation, when you're shipping a B2B product into the security space, is to wire up SSO/SCIM as a "we have it" checkbox and let customers figure out the configuration on their own. We didn't want to do that.

The reason is straightforward: every customer we'd talked to had at least one story about an identity integration they couldn't trust. The token had to be reissued every quarter. The provisioning would silently fall behind by hours. The deactivation would not actually deactivate. None of those things tend to surface until they matter.

So we worked through the OIN partner review with Okta directly. Multiple cycles of QA. Documentation rewrites. Mapping every attribute the SCIM spec requires, and only those. Removing every feature we didn't actually support in production (we don't import users — Butterfly is never the source of truth for a user profile — so we removed Import New Users from the supported list rather than implement it badly). Validating that the integration behaves the way it claims to behave when an admin runs Okta's automated test suite against it.

The result is that the listing reads as small and focused, which it is. We'd rather ship the integration we tested end-to-end than the longer one with caveats.

What's next

Universal Logout is the obvious thing missing. We have a back-channel logout endpoint working and the protocol implementation passes our test suite, but the OIN review surfaced behaviors we want to nail down before we publish that piece. It'll come in a near-term release. Until then, deactivating a user via SCIM revokes their access — refresh tokens immediately, in-flight access tokens within their TTL.

Microsoft Entra ID and Google Workspace are in joint review with their respective providers. Same process: we don't list a provider as supported until we've worked through the partner review and shipped a real integration. Two more identity providers, one-click installable, near-term.

Try it

If your team uses Okta, the install is in the OIN catalog now. The configuration guide walks through SSO and SCIM setup end-to-end and includes the role permissions matrix.

If you want a closer look at what Butterfly actually does once your team is in, the platform demo runs through backup, restore preview, compliance scanning, and the Chrome extension that ships alongside the platform.

We built this for the identity teams who keep getting paged at 11pm because someone changed a sign-on policy. The OIN listing is one less thing you have to wire up by hand. Welcome aboard.