Skip to content

Account Security

Featureflip gives you two ways to strengthen how you sign in: two-factor authentication (2FA) adds a one-time code on top of your password, and social sign-in lets you use your Google or GitHub account instead of a separate password. Both are managed from your account, and you can use either, both, or neither.

Two-factor authentication asks for a one-time code from an authenticator app in addition to your password, so a leaked password alone is not enough to sign in. Featureflip uses standard time-based one-time codes (TOTP), which work with any authenticator app — Google Authenticator, 1Password, Authy, and others.

  1. Go to your Profile page.
  2. Find the Two-Factor Authentication card and click Set up two-factor.
  3. Scan the QR code with your authenticator app. If you cannot scan it, enter the shown key into the app manually.
  4. Enter the 6-digit code from your app and click Enable.
  5. Featureflip shows your recovery codes. Save them somewhere safe — see below.

Once enabled, every future sign-in asks for a code from your authenticator app after your password.

When you enable 2FA, Featureflip gives you a set of recovery codes. Each code works once and is your backup way to sign in if you lose access to your authenticator app (for example, if you replace your phone). Store them somewhere separate from your password manager’s 2FA entry — printed, or in a secure note.

If you use some of your codes or want a fresh set, click Regenerate recovery codes on the Two-Factor Authentication card and confirm with your password. Regenerating invalidates your previous codes and replaces them with a new set. An account with no password (one you signed up for with Google or GitHub) confirms with a current code from your authenticator app, or with a recovery code, which is then used up.

After you enter your email and password, Featureflip prompts for your one-time code. Open your authenticator app, enter the current 6-digit code, and you are signed in. If you cannot reach your authenticator, use one of your recovery codes instead.

  1. Go to your Profile page.
  2. On the Two-Factor Authentication card, click Disable two-factor.
  3. Enter your password to confirm. If your account has no password because you signed up with Google or GitHub, enter a current code from your authenticator app or one of your recovery codes instead. A recovery code used here is used up. Wrong codes count toward the same temporary lockout as wrong passwords.

Two-factor authentication is turned off, and future sign-ins ask for your password only.

If an organization you belong to requires two-factor authentication, the Disable two-factor button is locked and the card names the organization. Leave it, or ask an Owner to stop requiring it, and the button works again.

Requiring two-factor authentication for your organization

Section titled “Requiring two-factor authentication for your organization”

On the Team plan and above, an Owner can make two-factor authentication mandatory for everyone in the organization. Turn it on under Organization Settings → Security policies → Require two-factor authentication.

Once it’s on:

  • Members without 2FA have to set it up. The next time they open Featureflip, they get a setup screen that names your organization, and nothing else loads until they finish. This holds for every way into the organization’s data, including the Management API, the MCP server and Terraform: a personal access token belonging to someone without 2FA is refused with two_factor_required.
  • Anyone who already has 2FA can’t turn it off while they belong to the organization.
  • The strictest organization wins. Someone in two organizations, only one of which requires 2FA, still has to set it up before they can use either. The setup screen tells them which organization asked.
  • Service tokens aren’t affected. A service token belongs to the organization itself, and an organization has no phone to read a code from.

Pick a grace period of 0, 7 or 14 days. During it, members without 2FA keep working and see a banner with the date their access stops. It counts from the moment you turned the requirement on. Shorten it from 14 days to 7 a few days in, and the deadline moves a week closer. Someone who joins after the deadline has to set up 2FA right away.

The 2FA column in the members list shows who has it on. Only Owners and Admins see that column.

If the organization requires single sign-on, a member who signs in through your identity provider doesn’t need a Featureflip code as well. Your IdP is the place to enforce MFA for those sign-ins. Everyone else still needs 2FA: an Owner using the password recovery path, and anyone signing in while the connection is set up but not required. The count of members without 2FA on the Security policies card leaves out the people who can only sign in through your identity provider, since the requirement never stops them.

Featureflip won’t let you require 2FA until your own account has it, so the Owner who flips the switch always passes it. That works for an Owner who signed up with Google or GitHub and has no Featureflip password, too: on the Team plan and above, you can set up 2FA from your profile before turning the requirement on. Other Owners without 2FA are held to the same rule as everyone else, and the setup screen is always open to them. That includes a deactivated organization. Its requirement still applies to its Owners, so an Owner without 2FA gets the setup screen when they open that organization, and can reactivate it once they finish. Their other organizations aren’t held back by it.

Turning the requirement off works on any plan. If your organization moves to the Free plan, the requirement stays in force until an Owner turns it off, so a billing change never quietly weakens it. Each change to the setting is recorded in the audit log.

You can sign up and sign in to Featureflip with your Google or GitHub account instead of a password. On the sign-in screen, click Continue with Google or Continue with GitHub, complete that provider’s consent screen, and Featureflip creates or signs you into your account from your verified email address there.

  • New to Featureflip? Continuing with a provider creates your account from your profile there, with no separate password to set.
  • Already have a Featureflip account under the same email address? If that account’s email is already verified, signing in with the provider links to it, so you can use either your password or the provider going forward. If the email on the existing account has not been verified, Featureflip will not automatically link the two, as a safeguard against account takeover. Verify the account first.
  • Two-factor authentication still applies. With 2FA enabled, Featureflip asks for your one-time code once the provider hands you back, exactly as it does after a password.

GitHub sign-in asks for the user:email scope, and Featureflip uses it to read your primary address along with GitHub’s own record of whether that address is verified. Google signs you in over OpenID Connect, which carries verification status in the sign-in response itself. GitHub uses OAuth 2.0, where that status is absent from the response, so the address has to be read from your GitHub account directly.

That has two consequences. Your public GitHub profile address is ignored when it differs from your primary one, so your Featureflip account is always created under the address that was checked. And a GitHub account whose primary address is unverified is turned away, because nobody has confirmed that the person signing in controls it.

Social sign-in is built on each provider’s OAuth. It is separate from single sign-on through your organization’s identity provider. OIDC single sign-on is on the Business plan, with setup guides for Okta and Microsoft Entra ID, and SAML / SCIM on Enterprise. Contact us if your organization needs SAML.

  • Team Management — invite members and manage roles for your organization
  • Audit Log — review changes made across your flags and environments
  • Security at Featureflip — where your data is stored, how SDK keys limit exposure, and how to report a vulnerability