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.

The email address in the members list

The list under Members shows each member by the address they currently sign in with. If someone changes their address at their identity provider, Resilic picks it up at their next sign-in, so the list does not go stale.

Two things worth knowing:

• The address is a label, not an identifier. Access rests on the account at the identity provider, not on the address; changing it changes no role, permission or history.
• Only an address the provider has verified is adopted, and only if it does not already belong to another member of your organisation. Otherwise the existing entry stands.

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.