Team and roles: inviting members, built-in roles and custom roles
Access to a Plexicus organization is role-based, and the Team page shows one role per member.
Inviting a member
Open Settings Team , click Add member, and fill in the Invite a team member dialog: an Email address and a Role. Then click Send invitation.
Invitations are for new users. The invitee gets an email to create a Plexicus account and join your organization. An address that already has a Plexicus account can’t be invited, and the response is deliberately generic so it doesn’t reveal whether that account exists. Ask new colleagues to wait for your invitation rather than sign up first: a self-service registration normally creates a separate organization with that person as its Admin. Each user belongs to exactly one organization; there is no organization switcher.
The member shows as Invited until they accept, then Active. Invitation links expire, so if a colleague misses the window, invite the address again; re-inviting a pending address with a different role updates that invitation. Pick a built-in role when you invite, and move the member to a custom role from the Team page once they have joined.
With SSO and just-in-time provisioning, people get their account the first time they sign in through your identity provider, so you don’t invite them one by one (lesson 2).
Changing roles and removing members
Use the role dropdown in a member’s row to change their role. The new role is assigned, the previous one is revoked, and the toast “Role assignment updated” confirms it. Remove on a row removes an active member or cancels a pending invitation. Both actions are written to the audit log. When an engineer leaves, remove them the same day, then filter the audit log by their email to review their recent actions.
Built-in roles
By default, the built-in roles split duties like this:
| Role | Typical holder | What it can do | What it can’t do |
|---|---|---|---|
| Admin | Platform owner, security lead | Organization settings and connectors, members, roles, findings, repositories and scans, AI pentests, ticketing and automations, billing, the audit log | Configuring SSO may need separate SSO administration rights (lesson 2) |
| Cyberoper | Security engineer | Triage findings (update, mark false positive, delete, send to developers), import reports, generate remediations and issues, create, run and cancel AI pentests, request scans, manage repositories, registries and source-control connections; read automations | Open pull requests, invite members, manage roles, read the audit log |
| Developer | Engineer who fixes code | View findings, remediations, repositories, scan runs and AI Pentest results; open pull requests and issues, send tickets, download reports and exports (PDF and JSON); read automations | Change finding status or mark false positives, generate fixes, start scans, run pentests, administer the organization |
With the default roles, a Cyberoper prepares and reviews a fix and a Developer opens the pull request. Module 7 covers that handoff.
Custom roles
Depending on your plan, Admins can build roles under Settings Roles . The table lists every role with its Role Name, Description, Type (a Built-in or Custom badge) and Members, the number of people who hold it.
Click Create role, enter a Role Name and a Description, and tick permissions in the grid. The grid is grouped by resource, such as Client, Finding, Repository, Remediation and Scan, and each entry carries an action of read, write or admin. Save stays disabled until the role has a name and at least one permission, and names must be unique in your organization.
Built-in roles can’t be renamed or deleted. On the Roles page their row offers only Duplicate, which opens the create form prefilled with that role’s permissions; custom roles show Edit and Delete.
For example, you want a “Security Lead” who works like a Cyberoper but can’t delete findings. Duplicate Cyberoper, name the copy Security Lead, clear the finding-deletion permission in the Finding group, save, and assign it from the Team page.
Identity: single sign-on, SCIM, two-factor authentication and passkeys
Users sign in with GitHub, Google or Microsoft, with email and password, with a passkey, or through Login via SSO, where they type your organization’s SSO login slug. Authentication settings live under Settings Authentication , with rows for Two-factor authentication, SAML / SSO, Passkey and Active sessions.
Setting up SSO
Open the SSO hub at Settings Authentication SAML / SSO Configure SSO . Configuring SSO needs SSO administration rights, which the documentation assigns to Admins; if the page refuses you, ask Plexicus support who in your organization holds them. The hub shows the status, mode and SSO Login Slug, the provider picker, Verified Domains, SCIM 2.0 Provisioning, the Advanced settings link to the Advanced SSO Settings page, and Disable SSO, which deletes the configuration. Which providers you can use depends on your plan.
| Picker option | Protocol | What you supply |
|---|---|---|
| Okta, Azure AD / Entra ID | SAML 2.0 | Guided wizard |
| Google Workspace | OIDC (recommended) or SAML 2.0 | Guided wizard |
| Ironchip | SAML 2.0 or OIDC | Guided wizard |
| Generic SAML 2.0 | SAML 2.0 | IdP Entity ID, IdP SSO URL and X.509 certificate; signed assertions required by default |
| Generic OIDC | OpenID Connect | Client ID, Client Secret, Discovery URL and scopes; PKCE on by default |
The slug is 3 to 64 characters of lowercase letters, digits, hyphens or dots, and must be unique across all Plexicus organizations. The service-provider values the wizards show, such as the ACS URL, Entity ID and OIDC redirect URI, contain it, so if you change the slug, update them in your identity provider. Each guided wizard ends with Test, a dry-run validation that saves nothing, and Activate, which saves the configuration.
Advanced settings: mode, JIT and group mapping
On the Advanced SSO Settings page (the Advanced settings link in the hub) you choose the Authentication Mode. Changes take effect on each user’s next login.
| Mode | Behavior |
|---|---|
| Coexist (default) | SSO and password login both work |
| SSO Preferred | SSO is the default; password login stays as a fallback |
| SSO Enforced | Intended as the only way in; the product describes password and passkey logins as disabled |
JIT Provisioning, on by default, creates an account on a user’s first SSO login with the default role (developer unless you change it). Group → Role Mappings override that: the first matching IdP group sets the role. If your organization has verified domains, only emails on those domains are provisioned, and an email that belongs to another organization is rejected. In current releases, mappings are re-evaluated at each SSO sign-in: move someone to another IdP group and their role changes at their next sign-in, with an audit log entry. For users who belong to a mapped group, manage the role in your identity provider; a change on the Team page may be overwritten at their next sign-in.
SCIM provisioning
The hub shows your SCIM Endpoint. Create SCIM Token issues a token valid for 365 days and shows it only once. Rotate issues a new token and keeps the old one working for 7 days; Revoke stops a token immediately. Tokens with fewer than 30 days left show Expiring soon. SCIM covers users and groups, so a user your identity provider deactivates loses access without a manual step.
Two-factor authentication and passkeys
To turn on 2FA, click the toggle on the Two-factor authentication row, scan the QR code with an authenticator app, and enter the 6-digit code. The row then shows Manage.
A passkey signs you in with a fingerprint, your face or a security key: click Set up on the Passkey row, then Continue in Link this device. Under SSO, the Passkey row reads Managed by SSO, and passkeys are configured in your identity provider instead. The Two-factor authentication row is unchanged.
The audit log: what is recorded, filtering and integrity
The audit log answers “who did what, and when” for your whole organization. Depending on your plan, Admins can open it at Settings Audit Log ; other roles can’t.
What you see
Each row has a Timestamp, an Actor Type (User, System or Integration), the Actor, the Action, the Resource Type, the Resource and Details. The eye icon in Details opens the full record with its metadata. Passwords, tokens, API keys, client secrets, certificates and cookies are replaced with [redacted] before an entry is stored, so the log doesn’t become a second copy of your secrets.
Filtering
You can combine four filters: a Date range picker (with presets such as Last 7 days, Last 14 days and Last 30 days), Actor email (a partial match), Action Type and Resource Type (User, Client, Repository, Finding, Remediation, Connector or Role). Results come 50 to a page with previous and next buttons, and a reset button clears the filters.
The Action Type list covers the most common administrative actions:
| Resource | Actions |
|---|---|
| Users | user.invited, user.removed |
| Organization | client.settings_updated |
| Repositories | repository.created, repository.deleted, repository.scan_triggered |
| Connectors | connector.added, connector.removed |
| Remediation | remediation.created, remediation.updated |
| Findings | finding.status_changed |
| Roles | role.created, role.deleted, role.assigned, role.revoked |
The log records more than that list. It also captures sign-ins and sign-outs, password changes, API token creation and revocation, passkey registration, CSV and JSON (SARIF) exports of findings, automation changes, SCIM user and group changes, SSO configuration changes and SSO sign-ins, and role changes that come from IdP group mapping. Opening the audit log is recorded too, so reviewing it leaves a trace of its own.
Verifying integrity
The log is tamper-evident. Each entry stores a SHA-256 hash that is linked to the previous entry for your organization. If anyone modifies or deletes an entry, the chain breaks at that point, and hiding it would mean rewriting every later entry.
You check the chain through the Plexicus API. An Admin can call the Verify Audit Log Chain Integrity endpoint at /audit-logs/integrity-verification. It recomputes the chain and returns valid: true when everything matches, or valid: false with a first_break pointer to the first entry where the chain breaks. Entries written before hash chaining reached your deployment are counted as pre-chain records and left out of the verdict, and the check covers only the entries your organization still retains. Module 9 covers API tokens and calling the API.
Using it as evidence
Retention depends on your plan and, on self-hosted installs, on your configuration. If an auditor needs a longer window, pull the entries you need through the List Audit Logs API before they age out.
The audit log supports access reviews, incident timelines and auditor requests. Plexicus provides the record and its integrity proof; whether your controls satisfy a framework is for your auditors to decide.
Organization settings: profile, regulations, language, ownership, AI and plans
All administration lives under Settings in the left sidebar, in three groups. Organization holds Organization, Team, Roles and Ownership Verification. Configuration holds Integrations, Platform, Billing and BYOAI. My Account holds your own account, authentication, tokens and the Audit Log. Roles and Audit Log are visible only to Admins; a non-admin who opens their address directly gets a “Page not found” page. Billing and BYOAI appear depending on your plan.
Company profile and regulations
Open Settings Organization . The page has three tabs, and each saves only its own section with Save changes:
- Profile shows the organization name, billing email, organization ID and owner as read-only, plus editable company information: legal name, business email, company URL, parent company, global identity identifier and category.
- Locations holds headquarters, branch, service and data-processing locations, and subsidiaries.
- Regulations is where you track the frameworks you are audited against. Plexicus maps findings to them and produces evidence (module 8); some frameworks depend on your plan.
Language
Two language settings are easy to confuse. Scan & Report Language on Settings Platform is organization-wide: AI analysis, fix pull-request descriptions and exported PDF and JSON reports are produced in that language. App Language, a tab under Settings Account , changes only your own interface. Both offer English and Spanish. The Platform page also holds scanning and fix defaults (modules 3 and 7).
Ownership verification
The page at Settings Ownership Verification is where Admins manage organization-wide domains. A pentest target needs either a verified domain, which covers its subdomains, or app verification done in the AI Pentest wizard. App Verification here is a read-only record of the latter and may be empty depending on your release. Verified domains also decide which email domains SSO JIT provisioning accepts. Module 6 walks through both methods.
AI configuration
By default, scans run on the Plexicus platform models, and customer code is not used to train AI models. If your plan includes it, BYOAI at Settings BYOAI lets you replace them with your own models through your provider’s endpoint: a Fast model, a Smart model and a required Embeddings endpoint, saved together with Save BYOAI configuration. Each block has Test connection, and one Reset to Plexicus default clears all three. Module 7 explains what each slot does.
Plans and entitlements
Your plan decides which features and how much AI usage your organization has. Settings Billing (Billing & Usage) shows the plan, renewal date, your AI usage allowance with this month’s usage and its reset date, pentest session usage and Invoice History. Your profile menu shows the same meters. Where your release includes it, a Usage page under Settings adds a per-action breakdown and history. Allowances reset on the 1st of each calendar month (UTC). A feature outside your plan shows an upgrade prompt or a Request Priority Access dialog. Module 7 explains what draws on the allowance and what happens when it runs out.
On Plexicus SaaS, Plexicus takes no payments in the application. An Admin selects Request a plan change under Billing, chooses the plan and billing interval, describes the expected usage, and sends it. An organization can have one open request at a time, which you follow under Settings Billing Plan requests .
| Status | Meaning |
|---|---|
| Received | Plexicus has your request |
| In contact | The team is working on it with you |
| Offer sent | An offer is ready for you to review |
| Invoiced | You accepted the offer and the invoice was issued |
| Paid | The invoice was paid |
| Plan applied | Your new plan is active |
| Rejected / Cancelled | The request was closed; you can send a new one |
Deployment options for platform owners
Plexicus runs as SaaS or self-hosted; air-gapped is a variant of self-hosted.
| Option | Where it runs | Who operates it |
|---|---|---|
| EU SaaS | Plexicus-hosted at app.plexicus.ai; SaaS data stays in the EU by default | Plexicus, including updates |
| Self-hosted | Your Kubernetes cluster, on premises or in a cloud account you control, installed with the Plexicus Helm chart | Your team |
| Air-gapped (self-hosted variant) | The self-hosted install with no outbound internet | Your team |
During maintenance, the app shows a System Under Maintenance page, or Upcoming Update System while a new version rolls out, and some features may be briefly unavailable.
Self-hosted with the Helm chart
Self-hosted and on-premises are the same thing: one chart and one license. You need any CNCF-conformant Kubernetes cluster at v1.25 or later. Plexicus hands you a delivery package with a registry credential, your signed license, an environment file with your chart version and AI settings, and, for production, a values file seeded with your domain. You provide the cluster, a domain with DNS records for the app and the API host, an ingress controller, TLS through cert-manager or your own certificates, a storage class that retains volumes, and ideally an SMTP relay. Without email, you declare the install as running without it, and invitations become admin-mediated: the invite response returns a verification link to the inviting Admin, who hands it over directly. Without email, creating the very first Admin also needs an extra setup step from the installation guide.
A self-hosted deployment sends no telemetry outside your cluster. Only the integrations you configure talk to external systems, and features that depend on Plexicus’ commercial services, such as billing, are disabled.
The license is installed as a cluster secret before you install the chart; without it, the core services don’t start. When the license is close to expiry (30 days or less), the login page shows “License expiring soon”. After expiry comes a grace period, 14 days by default, and then “License expired”, when access is restricted until you renew through your account manager.
Air-gapped installs
Air-gapped is the Helm path plus three changes: mirror every image into an internal registry, point the chart at that mirror, and replace the public certificate authority with your internal issuer. Transfer the license file through your normal secure process; license checks keep working offline. Leave integrations that need the public internet unset, and give the platform an AI endpoint it can reach, including an embeddings endpoint, or Deep Code Analysis can’t run. To upgrade, mirror the new release first, then run the upgrade with that exact version.
GitOps
If you already run ArgoCD, it can reconcile the same chart from Git instead of a manual helm install. The reference manifests ship inside the chart. Pin the chart to an exact version, keep values in Git, and never commit raw secrets: use sealed secrets, an external secrets operator or encrypted files.
Backup and restore
Platform state lives in three places: the main database (findings, users, repositories, scan results), the workflow-history database, and object storage (scan artifacts, AI inputs and outputs, reports). Back up all three together, because a database backup alone can point at artifacts you no longer have.
Plexicus is a workload on your cluster. Cluster provisioning, host hardening, DNS, TLS trust, network policy, monitoring and backups stay your responsibility.
Key takeaways
- Invite people from Settings Team before they register on their own, give them the narrowest role that fits, and use Duplicate to turn a built-in role into a custom one.
- SSO supports SAML 2.0 and OIDC through guided wizards or generic setups. Move from Coexist to SSO Enforced only after a dry run that passed within 24 hours, and let JIT, group mappings and SCIM keep accounts in sync with your identity provider.
- Users can add an authenticator app and a passkey; when your organization uses SSO, passkeys are managed in your identity provider instead.
- The audit log is for Admins, filterable by date, actor, action and resource, redacts secret-bearing fields, and is protected by a SHA-256 hash chain you verify through the API.
- Organization settings cover the company profile, regulations, two separate language settings, ownership verification, BYOAI and plan change requests; on SaaS, Plexicus takes no payments in the application.
- Self-hosted runs the same product from the Helm chart with a signed license; air-gapped adds mirroring and an internal issuer, and every upgrade starts with a backup of all three data stores.
Knowledge check
Check your understanding
Practice questions for this module. They do not count toward certification. Pass mark: 4 correct answers.