← All updates

Organization roles and security hardening

Organization roles

We rebuilt how access works inside an organization. Instead of assigning one capability template per member, every member now carries two roles you set independently: a vault role for what they can manage, and an access role for which projects they can reach. The two are separate on purpose, so a member's management authority and their access to secrets never have to move together.

Vault roles

A vault role sets what a member can manage across the whole vault: other members, billing, applications, and settings. The built-in tiers run from Owner, with full control, down through Admin, Developer, and Collaborator, each with less management authority than the last. When those do not fit, you can define a custom vault role with exactly the capabilities you want. A member can only assign roles at or below their own level.

organization-template-editor

Access roles

An access role governs which applications and projects a member can reach, and what they can do inside them, from read-only access through managing secrets, machines, and rotation schedules. You can scope a role to a single project or span several, and build custom access roles for the exact shape your team needs.

You assign both roles when you invite a member, and can change either at any time from your organization settings.

organization-project-scope

Documentation

We rewrote the heart of the documentation to make it easier to get started and to understand how SikkerKey fits together:

Security hardening

As part of our ongoing security review, we shipped a round of hardening:

These are all SikkerKey internal changes, so there is nothing to update in your SDKs, CLI, or machines.