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, give each a role that says what they can manage and which projects they can reach, 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 holds two roles, and they answer two different questions:

  • A vault role decides what the member can do across the vault: manage machines, read the audit log, configure alerts, invite people, manage billing. It carries no project access. A member holds one of four built-in roles (Owner, Admin, Developer, Collaborator) or an enterprise custom role.
  • An access role decides which applications and projects the member can reach, and what they can do inside each: manage secrets, attach machines, write access policies.

The two are independent, so you can pair a management tier with a project scope that suit each person separately. A new member starts on the minimal Collaborator vault role with no access role, so they can sign in and see the vault's name but reach no project until you assign one. The full model is in Vault Roles & Access Roles.

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