Overview

How Organizations let multiple SikkerKey users collaborate inside a single vault.

An organization is a vault that accepts more than one human user. Invite people you work with, assign each a permission template, and every action they take is attributed to them in the audit log. The vault, its projects, secrets, and machines stay exactly where they are. What changes is who can act on them and what they can do.

Every SikkerKey account starts as a personal vault. Owners convert their vault to an organization when they want others to share access. The conversion is one-way: once a vault is an organization, it stays an organization. There is no equivalent rollback.

What an Organization is for

You'd convert when one of these starts to matter:

  • More than one human needs to act on the same secrets, machines, or projects.
  • You want each person's actions attributed individually in the audit log.
  • You want to scope what each person can do, instead of sharing one set of credentials.

If you're the only person who acts on the vault, a personal vault is still the right shape. There is no benefit to converting until a second human is on the way in.

How members get in

The owner sends an invite by email. The recipient must already have a SikkerKey account, since membership joins an existing user identity to your vault. Once they accept, they appear in your member roster and they pick your vault from the post-login picker whenever they log in.

Members hold their own SikkerKey credentials. They sign in as themselves, then choose which vault to act inside for that session. The owner never sees the member's password or 2FA factors.

How members are scoped

Each member is assigned a template that bundles capabilities (what the member can do) and a project scope (which projects those capabilities apply to). Templates are authored by the owner; the same template can be assigned to many members. Changing a template's capabilities affects every member who holds it.

  • Capabilities are checkable cells across categories like Machines, Secrets, Audit log, Alerts, Templates, Organization, and so on. Some are vault-wide (the member can see every machine in the vault), some are project-scoped (the member can only manage secrets in the projects they're scoped to).
  • Project scope is either global (every project in the vault) or specific (only the projects in the member's scope list). Project-scoped capabilities ignore projects outside that scope.

Members with no template have no capabilities. They can sign in, see the vault's name in the picker, and that's it. They become functional once the owner assigns them a template.

The two trust planes

Organizations live entirely on the dashboard trust plane. Machines that read secrets at runtime still authenticate with their own Ed25519 keypair against the vault — the way they always have. Membership in an organization is a human-side concept; it has no effect on how machines prove themselves or what secrets they can read.

That separation is deliberate. A compromised dashboard session, however bad, never gives the attacker a machine identity. A compromised machine never grants dashboard access. The two planes are crossed only by the owner (or a member with the right capability) explicitly attaching a machine to a project or granting it a secret.

Where to next