Enforcing two-factor authentication

Two-factor authentication is always required for every account with an owner or admin role in your organization. This baseline is a platform-level policy that you cannot disable, and it applies the moment someone is promoted into one of those roles. On top of that floor, you can optionally require MFA for the rest of your working team (staff, employees, and organizers) from your workspace's Security settings.

Who it applies to

The unconditional enforcement triggers when an account holds the role of owner or admin in any organization on OrganizeOS. The check is per-account, not per-org: if a single member is an admin in your organization and an organizer in three other orgs, the requirement fires because of the admin role.

Below the owner/admin floor, whether the requirement applies depends on your org's two-factor policy, set at Settings, then Security:

• Off — staff, employees, and organizers can enroll voluntarily but are not required to. This is the default.
• Grace period for new members — a team member has a configurable window (1-90 days) from the day they join before enrollment is enforced. After the grace period elapses, they're routed to enrollment on their next sign-in just like an owner or admin.
• Fully required — every team member (staff, employee, or organizer role) must enroll before they can do anything else, with no grace period.

Regular members and supporters are never subject to any of these policies, regardless of what you configure.

When you change a member's role to owner or admin via your People settings, the next time they sign in (or, if they're already signed in, the next time their session refreshes) they'll be sent through MFA enrollment. They keep working as normal until that next sign-in, so the promotion takes effect immediately for permissions but the MFA prompt waits for their next entry point. There's no separate notification you need to send them; the flow walks them through it.

What the experience looks like for an affected account

The next time an affected account signs in (or the moment a role is changed to owner or admin), the platform routes them to the MFA enrollment flow instead of the dashboard. They see a QR code, scan it with an authenticator app, enter a verification code, and save their recovery codes. The flow takes about a minute.

Until they complete it, they cannot reach the rest of the app. There is no "do it later" option for owners and admins. Existing sessions that pre-date the requirement are also routed to enrollment before they can perform anything else.

Once enrolled, every subsequent sign-in asks for both their password and a six-digit code.

What if an affected account loses access to their authenticator

They sign in with their password, click Use a recovery code on the second screen, and enter one of the codes they saved at enrollment. They're in for that session, and their existing authenticator is removed from the account. The next sign-in routes them through enrollment for a fresh authenticator.

If they don't have recovery codes, they need to ask a platform admin to reset their MFA, which is a manual process. Make sure your owners and admins know to save their recovery codes when they enroll. See two-factor authentication for the member-side details.

Verifying enrollment status across your team

OrganizeOS does not currently surface a team-wide MFA enrollment report in the admin UI. The enforcement is gating: a person who isn't enrolled simply can't reach anything as an admin, so the practical view is "anyone who is actually doing admin things has enrolled." If you need a literal census, ask your owners and admins directly.

A team-wide enrollment dashboard is on the roadmap.

Why this matters

The blast radius of a compromised owner or admin account is the whole org. Member accounts have limited write access by RLS; admin accounts can change settings, view sensitive contact data, and modify roles. Requiring 2FA on these accounts is the cheapest possible defense against the most common attack pattern (credential reuse from a breach of an unrelated service) and the highest-leverage control you can put between an attacker and your organization. A single compromised admin credential is enough to alter roles, expose contact data, and change org-wide settings, so the requirement is not optional.