Team, roles & four-eyes

Access in Resilic is permission-based: roles are bundles of permissions, and every action checks a permission — never a role name. Invite team members under Members, assign roles under Roles.

Built-in roles

• Owner — everything, including billing and deleting the organisation.
• Admin — day-to-day administration: members, roles, settings, all content work and approvals.
• Member — the working role: creates and edits products, SBOMs, reports, policies — and may also approve. Right for small teams where the same people draft and sign.
• Approver — reviews and signs, never drafts: holds every approval permission (reports, policies, technical documentation, security advisories, risk assessments, Annex I) and no write permission. Assign it to the people who sign off compliance artifacts.
• Viewer — read-only, including the audit log.

Four-eyes (drafter/approver separation)

Every human-sign artifact has its own approval permission, separate from the write permission that creates and edits it. Out of the box, Member holds both — deliberate, so small teams aren’t blocked. To enforce separation: give drafting staff a custom role with write permissions only, and signing staff the Approver role. The audit log records who drafted and who approved either way.

Strict four-eyes (approver ≠ author)

By default a person with approval rights may both draft and sign an artifact — the right call for a small team. Enterprises can enforce genuine separation: turn on strict four-eyes (Roles screen) and the approver of a technical documentation file, security advisory, risk assessment, or Annex I conformance must be someone other than its last editor. The server rejects a self-approval with a clear message; a colleague with approval rights signs instead. Drafts created before the setting existed simply record their author on the next edit.

Product groups — restricting members to production lines

Roles say what a member can do; product groups say on which products. Create named groups (“Production line X”) on the Roles screen and restrict a member to one or more of them: their product register, fleet views, vulnerabilities, and everything derived narrows to those groups — silently, everywhere. A product they cannot see answers exactly like one that does not exist.

Three rules keep this predictable:

• Empty scope = all products — every member starts unscoped, and nothing changes until you restrict them.
• Owners and Admins always see everything — scope cannot be assigned to them.
• Groups are the unit, not products: add a new machine to “Production line X” once and every member scoped to that line follows automatically. Deleting a group returns its members to unscoped; it never touches the products.

Scoping is intra-company need-to-know, not a security boundary between companies — that remains the tenant isolation underneath everything.

Single sign-on: provisioning from your identity provider

Enterprises can let membership follow their identity provider instead of adding people by hand. Your IdP (Entra ID, Okta, …) connects through our SSO; on the Roles screen you map each IdP group name to a Resilic role and optional product scope. When someone signs in through SSO carrying a mapped group, Resilic provisions them to that role and scope automatically — and keeps them in sync on every login:

• Joiners get access the first time they sign in with a mapped group.
• Role or scope changes in your directory take effect on their next login.
• Leavers — removed from every mapped group — are suspended automatically (access revoked, history kept).

For IdP-provisioned members the directory is authoritative: their role and scope are read-only in Resilic (change them via the group mapping). Members you add by hand are never affected by this. The manufacturer’s own bootstrap Owner always stays manual, so a mapping mistake can’t lock you out.

Custom roles

Under Roles you can define your own permission bundles. Two guardrails apply: nobody can grant a role carrying permissions they don’t hold themselves, and financial actions (checkout, billing portal) always require the settings permission.