Authentication & Recovery Codes
Signing in, two-factor recovery codes, and what to do if you're locked out
Recovery codes
Greenroom supports recovery codes as a second-factor fallback, so a lost phone or a locked-out authenticator app doesn't have to mean a locked-out account. From Settings → Me, under Sign-in security, you can:
- See how many of your 10 recovery codes are still unused
- Generate a set (or regenerate a full new set if you already have one)
- Turn email-based sign-in codes on or off as your fallback method
Generating or regenerating codes asks you to re-enter your password first — that way a session left open on a shared computer can't mint a new set on its own.
Regenerating replaces your entire set at once — every old code, used or not, stops working immediately. Store the new codes somewhere safe before closing the page; Greenroom cannot show them to you again after you navigate away.
Each code works exactly once, even if it's submitted twice at nearly the same time — only the first attempt succeeds, and the second is rejected the same way a wrong code would be.
If you're locked out
If you've lost access to your authenticator app or passkey and don't have a saved recovery code, contact Greenroom support — they can verify your identity and help restore access. Do not share a recovery code with anyone, including support staff; Greenroom will never ask you for one over email or phone.
For administrators
Recovery codes, authenticator apps, and passkeys are all scoped to the individual account that owns them — company managers don't have a way to view, reset, or regenerate a teammate's sign-in methods from inside Greenroom. That's a deliberate boundary, not a gap: it means one careless or compromised account on your team can't be used to reach into another. If someone on your team is genuinely locked out, have them contact Greenroom support directly rather than looking for an in-app override — recovery in that situation is handled and verified by Greenroom's own team.
How your data is protected
Greenroom is multi-tenant. Every request the application serves is scoped to the signed-in user's own company, so the product itself never lets one company read or write another's payees, pay rates, or tax data. As a second, independent layer, the database enforces that same boundary on its own: row-level security is enabled on every table, so nothing outside Greenroom's application — including the database's general-purpose data API — can read or write your data by default.
This section describes current architecture, not incident history. If you have specific compliance or security-review questions (SOC 2, data-processing agreements, penetration test results), contact Greenroom directly — that level of detail belongs in a signed agreement, not a public docs page.