Secure Configuration Guide

Last reviewed: 2026-08-26

This page covers Meterbox's two privileged-access surfaces: the organization owner account in the web dashboard, and API administrative credentials used against the billing API. It documents how to access, configure, operate, and decommission each, and which settings only these roles can change. Every recommendation below reflects Meterbox's actual default behavior — nothing here requires extra configuration to take effect.

1. Organization owner account (dashboard)

The owner is the top-level administrative role. The first user to sign up for an organization becomes its owner; every other member (additional owners, admins, or regular members) is added afterward by invitation.

Access

  • Sign in with a password (12–72 characters, must include a letter and a number, screened against a common-password list) or via OIDC single sign-on (Google or an enterprise identity provider). SSO authenticates an existing owner/admin/member — it does not create new accounts on first login.
  • Sessions are server-side, httpOnly, Secure, SameSite=Lax cookies. They expire after 30 minutes of inactivity (sliding) and after 12 hours regardless of activity — sign in again after either limit. Logging out explicitly clears session state on both the server and the browser.

Configure

  • Enable multi-factor authentication immediately after signup — Settings → Security → Multi-factor authentication. Meterbox uses TOTP (RFC 6238, compatible with any standard authenticator app) plus one-time backup codes for account recovery. Store backup codes somewhere separate from the device running your authenticator app.
  • Disabling MFA requires both the account password and a valid, current second-factor code — a stolen session alone cannot turn MFA off.
  • If your organization uses an enterprise identity provider, configure OIDC SSO under Settings → Security so sign-in is federated instead of password-based.

Operate

  • Invite additional team members by email with an explicit role (owner, admin, or member) from the Team page. Review the full team's access posture — role, MFA status, last login, last action, and an active / idle / stale classification — on the same page, or via a downloadable CSV.
  • Configure where security alerts (failed-login bursts, MFA failures, CSP violations) are sent — email to owners and admins is on by default; an HTTPS webhook (Slack-compatible JSON, also works with PagerDuty/Opsgenie) can be added under Settings → Security.
  • Review the append-only, hash-chained audit log of every administrative action at any time, and verify its integrity on demand — a broken hash chain is itself a signal worth investigating.

Decommission

  • Removing a member's role immediately revokes their sessions and membership — they lose access on their next request, not at their next token expiry.
  • Resetting a password revokes all of that account's active sessions, everywhere, automatically.
  • Deleting the organization purges its users and memberships and revokes every session in one action. This is irreversible — confirm you have exported anything you need first.

2. API administrative credentials

Owners and admins can mint API credentials scoped to one organization and one environment (production or sandbox) from Settings → API keys, or via POST /cp/api-keys. The plaintext secret (mb_live_... / mb_sandbox_...) is shown exactly once, at creation — store it in a secrets manager immediately, not in source control or a shared document.

  • Configure: give each key a descriptive label per integration/use so a leaked or misbehaving key can be identified quickly from GET /cp/api-keys, which lists every key for the org (masked) across both environments.
  • Operate: because the environment is baked into the key itself, a caller using it never needs to also pass an environment header — reducing the chance of a sandbox key accidentally hitting production, or vice versa.
  • Decommission: revoke a key immediately and permanently via DELETE /cp/api-keys/{id} the moment it is no longer needed or is suspected compromised. Revocation takes effect on the key's very next use.

3. Settings only owner/admin roles can change

These are gated to the owner and admin roles — regular members cannot see or change them:

  • Inviting, removing, or changing the role of any team member.
  • Minting or revoking API keys (Settings → API keys).
  • Security-alert notification channels (email recipients, webhook URL).
  • Data retention configuration and the audit-log export endpoint.
  • Deleting the organization (owner only — the single most destructive action available in the product).

4. Secure defaults

Every setting above ships secure by default: session timeouts, the password policy, TLS enforcement (HSTS), and the security-header baseline are all active without any configuration step. Multi-factor authentication is the one control we recommend but do not force on — enabling it for every owner and admin account is the single highest-leverage action you can take after signup.

Questions about this guide, or found something that doesn't match observed behavior? Email contact@meterbox.ai. See also the Trust Center for the full security architecture and control mapping.