Account security

Dashboard → Settings → Security is where you manage how you (and, by the same mechanisms, your teammates) authenticate: password, active sessions, and connected sign-in methods. This guide also covers API-key hygiene, which lives under Developers but is part of the same "keep your account and org locked down" story.

Password

If your account has a password set, the Change password card asks for your current password and a new one (minimum 8 characters). Changing it signs out your other active sessions as a safety measure — the device you're changing it from stays signed in.

If your account was created purely through an OAuth provider (Google, GitHub, or Discord) and never had a password, you'll see a set an initial password form instead — no current password field, because there isn't one to verify yet. Setting one gives you a password-based fallback login independent of whichever OAuth provider you originally signed up with. Both actions require the new password to be at least 8 characters; the button stays disabled until that's satisfied.

Sessions

Every device currently signed into your account is listed, each showing:

• A best-effort browser + OS label, parsed from that device's user agent (e.g. "Chrome on macOS").

• The device's IP address and how long ago it was last active (a compact relative time like "3h ago").

• A This device badge on whichever session you're viewing the page from.

Click Revoke on any other session to sign it out immediately — the right move right after losing a device, or if you spot an IP or user agent you don't recognize. Two broader actions sit below the session list:

Connected sign-in methods

The Connections card lets you link or unlink OAuth providers — Google, GitHub, and Discord — against your account. Each row shows whether it's connected (and the linked email, when the provider exposes one) or offers a connect button if it isn't.

You cannot disconnect your last remaining sign-in method. If you have no password set and only one OAuth connection, the disconnect action is blocked outright — this exists specifically so you can't accidentally lock yourself out of your own account. Set a password or link a second provider first if you want to freely swap providers later.

Enterprise SSO (SAML/OIDC) is a separate, organization-level capability gated to Pro and above (see Plans & billing) — it governs how your whole team authenticates into an org, rather than being a personal connection you toggle here. It isn't self-service from this page; talk to whoever administers your Cookie Munch instance to have it set up for your organization.

API-key hygiene

API keys authenticate programmatic access to the REST API and live under Developers → Keys, scoped to the current organization rather than to your personal account. Treat them with the same care as a password:

• Scope every key narrowly. When you issue a key, you choose which resource scopes it can use (consent, sites, DSAR, vendors, ROPA — each with independent read/write) plus a read-only receipts scope. Grant only what the integration actually needs; a key for a read-only reporting job shouldn't carry *:write scopes. Full-access keys work but widen your blast radius if the key ever leaks.

• Name your keys. The name field (up to 60 characters) is how you and your teammates will recognize what a key is for months later — "Zapier prod sync" beats "unnamed" every time you're deciding what's safe to revoke.

• Copy the secret immediately. After issuing (or rolling) a key, the dialog shows the raw secret once. Copy it into whatever secrets manager or environment variable store your integration uses right away — the dashboard never shows the full key value again after you close that dialog, only its prefix.

• Set an expiry when you can. The issue dialog offers never / 30 / 90 / 365 days. A key with a real expiry limits how long a leaked credential stays useful even if you never notice the leak.

• Roll, don't just rotate manually. Clicking Roll on an existing key issues a brand-new secret under the same name/scopes/expiry and immediately invalidates the old one — use this on a schedule, or the moment you suspect a key may have been exposed (committed to a repo, pasted somewhere public, etc.).

• Revoke keys you've stopped using. An unused key with broad scopes is pure downside — it does nothing for you and is one leak away from being a problem. The key table shows every key's scopes and expiry status at a glance (expired keys are visually dimmed with an "Expired" badge) specifically so stale, over-scoped keys are easy to spot during a cleanup pass.

Related: organization danger zone

Settings → Danger zone (a separate tab from Security) holds the destructive, confirmation-gated actions: deleting the current organization, or deleting your entire account. Both require typing DELETE into a confirmation field and are irreversible — deleting an org removes it (and everything scoped to it — properties, banners, consent history) for every member, not just you.

Tips and gotchas

• Changing your password signing out other sessions is expected behavior, not a bug — if you're mid-setup on another device, re-authenticate there after.

• If "Sign out everywhere" seems drastic, prefer revoking individual sessions first from the Sessions list — it's the more surgical option when you know exactly which device concerns you.

• A revealed API key secret is shown once. If you close the dialog without copying it, there's no way to retrieve that exact value again — you'll need to roll the key for a fresh one.

• Review Developers → Keys periodically the same way you'd review connected OAuth apps elsewhere — it's the most common place stale, over-privileged credentials accumulate unnoticed.

Next steps

• Organization & members — roles govern what a teammate can do once signed in; this page governs how they prove who they are.

• Plans & billing — where enterprise SSO sits in the tier lineup.