Roll out Safeguard enterprise-wide: SSO, SCIM, roles, audit log

Yes. Safeguard can be rolled out across many teams and business units behind your own identity provider. Sign-in uses SAML 2.0, OpenID Connect or Google, Microsoft and GitHub login, with SCIM 2.0 provisioning, passkey and TOTP multi-factor, built-in and custom roles, a tenant and organization hierarchy, and an append-only audit log you can stream to your SIEM.

The rest of this post is the long version for the head of AppSec or platform owner running the rollout and the identity architect signing it off: how each piece works according to Safeguard's own documentation, which settings to choose in what order, where the sharp edges are, and a phased plan.

Key takeaways

• Sign-in: SAML 2.0, OpenID Connect, and Google, Microsoft and GitHub login, configured under Settings, Authentication, Single Sign-On by a tenant Admin or Owner.
• Provisioning: a provisioning policy governs first SSO login (the default rejects email conflicts). SCIM 2.0 is documented for provisioning and deprovisioning, and SSO/SCIM is listed on the Enterprise tier.
• Multi-factor: WebAuthn and passkeys preferred, plus TOTP and FIDO2 keys. SMS is off by default.
• Roles: built-in and custom roles, scoped to the organization, a team or asset labels, with SSO group mapping.
• Hierarchy: tenant, organizations, projects, versions. Products group projects for combined risk.
• Audit: an append-only, cryptographically chained log of who, what, when, where and why, streamable to your SIEM.
• Rollout: pilot one team, put SSO, multi-factor and roles in first, run policies in Warn or Notify, then switch the gates that matter to Block.

What does an enterprise rollout of a security platform actually need?

Most security tools stall after the first enthusiastic team, when the twentieth team needs access. The blockers are about identity and control, not scanning:

1. Do people sign in with the corporate identity provider, so joiners, movers and leavers are handled in one place?
2. When someone leaves, does their access end, including keys and automation they created?
3. Can a payments team see its findings without seeing another unit's?
4. Can auditors read everything and change nothing?
5. Can a policy be set once and applied across every organization?
6. Can you prove who changed what, when, from where and why?

The sections below answer each with a documented mechanism, in the order you would build them.

How Safeguard models your company: tenant, organizations, projects and products

Decide how your company maps onto Safeguard's structure before anyone configures single sign-on, because roles and policies attach to it.

Safeguard's Organization and User Management page describes a hierarchy of tenant, then organizations, then projects, then versions. The tenant is the top-level container: a single billing entity with global settings, SSO configuration and API key management. Organizations are groupings inside it for business units, teams, portfolios and access boundaries. Each project is an SBOM generation target, a scanning unit and a policy scope.

Safeguard's offering notes describe the tree in its demo tenant: a root organization, then a technology group, then product engineering, then frontend and backend squads, alongside infrastructure and business operations. The top levels follow how the company is managed; the leaves follow who owns code.

Two more concepts sit on top of the hierarchy:

• Products group projects. A product can bundle several projects so you see combined risk across a release train or a business unit, and comparison works across projects, components and products.
• Publish and share are different actions. Publishing moves an artifact from the main platform (ESSCM) into Portal and creates an immutable copy. Sharing sends that artifact onward as-is. The difference matters when an auditor or a customer asks exactly what you retained and what you sent.

Safeguard's RBAC page describes the access side in slightly different words: organization, team, project and asset. A team is a group of users with shared access, assets (repositories, images, SBOMs, vendors, workloads) are assigned to projects, and a user can hold a different role in each team they belong to.

A practical way to draw your tree

Keep the hierarchy shallow. The organization management page recommends aligning with business structure, keeping it simple and documenting ownership.

For a tool-neutral treatment of this design problem, our post on modeling teams, products and repos in an SCA hierarchy covers the trade-offs, and products, projects, SBOMs and findings explains how Safeguard's data rolls up so you count vulnerabilities correctly once the tree exists.

Single sign-on: SAML 2.0, OpenID Connect and social login

Safeguard's SSO documentation lists five identity provider types: SAML 2.0, OpenID Connect (OIDC), and OAuth "social" login through Google, Microsoft and GitHub. A tier note before you plan: the web application page says SSO is supported for Enterprise tenants, while Safeguard's pricing notes list RBAC and SSO on the Team tier and SSO and SCIM on the Enterprise tier. These sources do not agree, so confirm which tier covers SSO for your tenant with Safeguard before you design around it. You configure all of them in the same place: sign in as a tenant Admin or Owner, open Settings, then Authentication, and scroll to the Single Sign-On section. From there you can add a provider, test it, or delete it.

Which protocol should you choose?

The SSO page gives a simple decision rule.

The OASIS SAML 2.0 technical overview describes two browser flows: SP-initiated, where the user starts at the application, and IdP-initiated, where the user starts from the identity provider's portal. SAML 2.0 supports both. OpenID Connect Core 1.0, from the OpenID Foundation, is an identity layer on OAuth 2.0 whose ID Token carries claims such as iss, sub and aud.

How sign-in works in Safeguard

The recommended path is SP-initiated: the user goes to https://app.safeguard.sh, enters an email address and is sent to the identity provider. That works for every provider type. IdP-initiated sign-in also works for SAML: Safeguard detects the unsolicited response at its broker endpoint and restarts it as an SP-initiated login, with no second prompt because the user is already authenticated. On first login, Safeguard applies the tenant's provisioning policy to decide whether to create the account, a choice that deserves its own decision.

Step by step: connect a SAML 2.0 identity provider

This walkthrough follows Safeguard's generic SAML steps, which apply to any identity provider. Safeguard's docs also include provider-specific guides; use the one for your provider alongside these steps.

1. In your identity provider, create a new SAML application.
2. Set the ACS URL (your provider may call it the Reply URL or Single Sign-On URL) to the value Safeguard shows after you save the provider. It follows the pattern https://api.safeguard.sh/auth/idp/realms/<tenantId>/broker/<alias>/endpoint.
3. Set the SP Entity ID (Audience) to the value Safeguard shows, which follows https://api.safeguard.sh/auth/idp/realms/<tenantId>.
4. Set the Name ID format to Email or EmailAddress and map it to the user's email.
5. Add an explicit attribute named exactly email, mapped to the user's email address. The docs call skipping this the most common reason a SAML login looks fully configured on both sides and still fails.
6. Collect three values from your identity provider: the SSO or login URL, its Entity ID or Issuer, and its X.509 signing certificate in PEM format.
7. In Safeguard, choose Add Provider, then SAML 2.0, and fill in the form:

8. Save, then copy the ACS URL, SP Entity ID and Metadata URL that Safeguard displays. Paste the ACS URL and SP Entity ID back into your identity provider if you have not already. The Metadata URL follows https://api.safeguard.sh/auth/api/v1/sso/metadata/<tenantId>/<alias> and some providers can import it instead of manual entry.
9. Assign users or groups to the application in your identity provider.
10. Back in Safeguard, choose Test next to the provider.

Watch the two Entity IDs. The identity provider's Entity ID goes into Safeguard; Safeguard's SP Entity ID goes into the identity provider. Echoing the provider's own value back into its Audience field makes it reject the request. Copy the ACS URL and SP Entity ID from the dialog rather than typing them, because they are specific to your tenant and to each provider's alias.

Step by step: connect an OpenID Connect provider

For any OIDC 1.0 compliant provider that is not covered by the dedicated social buttons:

1. Register a new confidential OIDC client in your identity provider.
2. Set its Redirect URI to Safeguard's callback, https://api.safeguard.sh/auth/api/v1/sso/callback.
3. Collect the Authorization, Token and UserInfo endpoint URLs (most providers publish them in a /.well-known/openid-configuration discovery document), plus the client ID and client secret.
4. In Safeguard, choose Add Provider, then OpenID Connect, and enter the alias, display name, the three endpoint URLs, the client ID and secret, and the default scopes.
5. Save, then Test.

The OIDC example in Safeguard's docs looks like this, with placeholder values:

Alias:              corp-oidc
Display Name:       Sign in with Corporate SSO
Authorization URL:  https://idp.example.com/realms/corp/protocol/openid-connect/auth
Token URL:          https://idp.example.com/realms/corp/protocol/openid-connect/token
User Info URL:      https://idp.example.com/realms/corp/protocol/openid-connect/userinfo
Client ID:          safeguard-oidc-client
Client Secret:      (from your identity provider, stored there and in Safeguard only)
Default Scopes:     openid profile email

A standards note for identity architects: OpenID Connect Core says only the sub and iss claims together are a stable user identifier, and a relying party must not rely on email being unique. Safeguard's SAML flow reads the email attribute and the provisioning policy links accounts by email, so make sure your directory never recycles an address to a new person before you switch on auto-linking.

Testing and the errors you will see

Use the Test button before rollout. The troubleshooting page lists the likely errors:

Deleting a provider does not revoke sessions created through it; users sign in again on their next session. If you remove a provider over a security concern, end sessions as well.

Provisioning: just-in-time, invite only, and SCIM

Single sign-on answers "who is this person?" Provisioning answers "should this person have an account at all, and with what access?" Safeguard handles the first login through a provisioning policy, and handles ongoing lifecycle through SCIM.

The provisioning policy on first SSO login

The Policy panel next to the provider list offers three modes:

The same panel has an Allow password login toggle; turn it off once SSO is fully rolled out. The RBAC docs add that Enterprise tenants can require SSO for every login and require re-authentication for sensitive actions such as policy changes and exception approvals. Just-in-time provisioning creates users with a default role you configure; the least privilege choice is a read-only role, with more granted through group mapping.

Mapping identity provider groups to Safeguard roles

The Organization and User Management page describes group mappings under Settings, SSO, Group Mappings, where each identity provider group maps to a Safeguard role and a set of organizations. The docs' example maps a security team group to Manager across all organizations, developers to User in an engineering organization, and auditors to Viewer everywhere. This is where a rollout scales or stalls: if roles come from groups your identity team already maintains, a person's Safeguard access follows their job instead of a ticket queue.

SCIM 2.0: what the standard does and what Safeguard documents

SCIM, the System for Cross-domain Identity Management, was published by the IETF in September 2015. RFC 7643 defines the JSON core schema for users and groups; RFC 7644 defines the HTTP protocol, with /Users and /Groups endpoints supporting create, read, replace, PATCH and delete, plus a /ServiceProviderConfig endpoint. For offboarding, the key attribute is active, a Boolean for the user's administrative status where false typically means the account is suspended. The identity provider is the client and pushes changes; a deactivation in the PATCH shape RFC 7644 defines looks like this:

PATCH /Users/2819c223-7f76-453a-919d-413861904646 HTTP/1.1
Content-Type: application/scim+json
Authorization: Bearer <provisioning token>

{
  "schemas": ["urn:ietf:params:scim:api:messages:2.0:PatchOp"],
  "Operations": [
    { "op": "replace", "path": "active", "value": false }
  ]
}

That example illustrates the standard, not a Safeguard endpoint. Here is what Safeguard's own documentation states about SCIM:

• Safeguard supports SCIM 2.0 for automated user provisioning and deprovisioning, listed alongside SAML 2.0, OIDC and just-in-time provisioning on the RBAC page.
• SCIM deprovisioning is triggered by your identity provider pushing a deactivation event to Safeguard, not by Safeguard polling the identity provider.
• When a user is deprovisioned, by SCIM or manually, Safeguard revokes all sessions, revokes all of the user's API keys, reassigns their pending approvals to their team, and keeps their past actions in the audit log.
• SSO and SCIM are listed on the Enterprise tier; the Team tier lists RBAC and SSO.

The documentation pages we reviewed do not publish a SCIM base URL, a token screen or the attributes Safeguard maps, so confirm those with Safeguard during onboarding. The docs also flag a timing issue on the identity provider side: some providers batch SCIM syncs instead of pushing immediately. For a time-sensitive offboarding, deprovision manually in Safeguard as well.

What deprovisioning does not touch

This is the paragraph most offboarding checklists miss. Safeguard's docs state that service tokens, workload identities and organization secret keys are not revoked when a user is deprovisioned, because they belong to a service identity or the organization. If the leaver created a CI service token or an organization secret key, revoke or rotate it separately.

Multi-factor authentication and sessions

Safeguard's RBAC page lists the supported second factors:

• WebAuthn and passkeys, which the docs mark as preferred.
• TOTP through authenticator apps.
• FIDO2 hardware security keys.

Phone and SMS based multi-factor is disabled by default. Safeguard's offering notes describe this as 2FA and 2SA support. Policies can also require a specific multi-factor level for specific actions; the docs' example is that promoting a self-heal to production requires a passkey re-authentication.

The standards behind these choices are worth citing in your design document. The W3C published Web Authentication Level 3 as a Recommendation on 25 August 2026, and its use cases describe phishing-resistant sign-in with multi-device credentials, commonly called synced passkeys. NIST SP 800-63B-4, published July 2025, requires a phishing-resistant authenticator with a non-exportable key at its highest assurance level, AAL3. It also treats the public telephone network for out-of-band codes as a restricted authenticator. TOTP itself is defined in RFC 6238 (May 2011). If your identity provider already enforces phishing-resistant factors, enforcing them there and using SSO is usually simpler than managing factors in each application.

Sessions follow the same rules however the user signed in. The web application docs give defaults of 8 hours idle and 24 hours absolute, which Enterprise tenants can tighten; SSO only establishes the session. Programmatic access uses separate credentials, covered below.

When SSO itself is down

Safeguard's account recovery page describes a Request access option on the login screen that emails every Tenant Admin with a link to invite or link the user's account. If password login is still enabled, password reset is a fallback. If SSO is the only method and no admin can get in, recovery goes through Safeguard support. Decide before go-live who your tenant admins are and how they reach support if all of them are locked out.

Roles and permissions: built-in, custom and scoped

This is the section where a careful reader of Safeguard's docs will notice something, so it is better to say it plainly. Safeguard's documentation describes more than one role vocabulary, and the RBAC page's own FAQ explains why: some product surfaces layer their own role names on top of the core model, for that surface only. When a permission looks wrong, the docs advise checking which role system the page you are on describes before assuming a bug.

Here are the three sets as the docs describe them.

Core organization and team roles (RBAC page)

Organization and user management roles (ESSCM page)

The Organization and User Management page uses Tenant Admin (full access to all organizations and settings), Manager (manages specific organizations, users and policies, inviting users only within assigned organizations), User (works with assigned projects, can create projects and configure integrations) and Viewer (read-only on assigned projects). Project-level access adds Admin, Write and Read. Safeguard's offering notes describe the same set with SSO group mapping, plus tenant admin and org admin scopes.

Portal roles

Portal, the SBOM publishing and sharing surface, has Admin, Manager, Contributor and Viewer, plus Customer Admin and Customer User for external recipients. For example, a Contributor can share externally only with approval, and only Admin and Manager can view Portal audit logs.

What to do with this during rollout: name the surface for each role in your mapping, and confirm which role list your tenant's Members and Roles screens show during the pilot, before you map dozens of groups.

Custom roles

When built-in roles do not fit, the RBAC page shows custom roles composed from a permissions matrix, with optional restrictions. The documented example is a production responder who can read and triage findings, evaluate policies and run workflows, restricted to production:

apiVersion: safeguard.sh/v1
kind: Role
metadata:
  name: production-responder
spec:
  permissions:
    - findings:read
    - findings:triage
    - policies:evaluate
    - workflows:run
  restrictions:
    environments: ["production"]
    severity_max: "critical"

The docs' debugging advice applies to every custom role you write: a restrictions block such as severity_max or environments silently narrows an otherwise broad permission. Check it first when a role does not grant what you expected, then check which team scope the resource falls under, because a user in several teams can hold different roles in each.

Portal has its own custom roles under Settings, Roles, built from permissions such as products.create, sboms.export, sharing.approve and admin.audit.

Per-asset permissions for contractors and narrow access

Permissions can also be sliced by asset labels. The documented example scopes a Security Engineer to assets labelled for the payments team in production and staging:

- role: Security Engineer
  scope:
    labels:
      team: payments
      env: [production, staging]

The docs describe this as useful for consultants and contractors who should only see one service.

Approval workflows and break-glass

Two documented controls handle the actions you do not want any single person to take alone.

Approval workflows (Settings, Approvals) can require multi-party approval for policy changes, large exception grants, production-impacting auto-fix merges, service token creation and organization-level configuration changes. The approver list for a specific guardrail exception is set in the policy rule itself, for example an exception.approvers field naming a security leads group.

Break-glass grants elevated permissions for a time-boxed window during incident response. Invocations require two approvers and notify the whole security team, and every break-glass action is labelled separately in the audit log for post-incident review.

A starting role map for a large engineering organization

Treat this as a template to adapt, using the role names your tenant shows.

API keys, service tokens, MCP access and other machine identities

People are only half of the identity problem. CI jobs, scripts and AI assistants also authenticate. Safeguard's RBAC page separates two families of long-lived credential.

The docs state that tokens are short-lived by default (a maximum of one hour unless explicitly extended) and that their usage is auditable. They also note there is no CLI command for generating these keys yet, so key creation is a console task.

Three practices follow. Prefer workload identities for CI, which remove a long-lived secret from pipeline configuration. Name every service token for its purpose and owner, and put service tokens and organization secret keys in the offboarding runbook. Rotate organization secret keys by creating the new key and reconfiguring instances before revoking the old one, because the docs say a revoked key fails every Guard SDK instance on its next policy sync.

MCP access for AI assistants

If your developers will drive Safeguard from an AI assistant over MCP, the platform owner controls which tools those assistants can see. Safeguard's tool gating page describes a per-tenant feature flag for every MCP tool. A new workspace starts with a small default set of read-only tools (listing and reading products, projects, vulnerabilities and findings), and every other tool, including those that add integrations or start scans, ships disabled until an administrator turns it on under Feature Flags. The same resolution governs discovery and execution, so an assistant can never see a tool it cannot call, or call a tool it cannot see. If resolution fails, the server falls back to the small default set rather than exposing anything wider.

Tool gating resolves per tenant, not per user. If you need finer control over what individual agents can do, the docs point to Guard, which applies allow, deny or monitor policies to tool calls. Our MCP key safety checklist covers key handling for assistant connections in more depth.

Shared policies and gates across organizations

Identity decides who can act. Policies and gates decide what the platform will accept. In an enterprise rollout, the goal is to define a policy once and apply it everywhere, with teams seeing the same result in the console, in CI and from an assistant. The Team tier lists shared policies and gates, and the offering describes policies, gates and guardrails as enforceable across the organization at build, CI and release.

According to Safeguard's Policies and Gates docs, a policy is a rule that evaluates your SBOMs and generates findings, and a gate is a checkpoint that enforces policies. Conditions include vulnerability severity, CVSS score, EPSS, license, component age, maintenance and SLSA level, and templates exist for common requirements. Each policy has one Action:

Per the policy outcomes page, any failed Block policy fails the gate; otherwise a policy that could not be evaluated gives an Error, never counted as a pass; otherwise a failed Warn policy gives a Warning, which passes. Policy outcomes are turned on per workspace by Safeguard, so ask your Safeguard contact if you do not see an Outcome column.

In CI, the documented command waits for the scan and the gate's policies, then exits on the gate's outcome:

# Fails the job when the named gate is Failed, Error or Not evaluated.
# Passes (exit 0) when the gate is Passed or Warning.
safeguard ci scan --wait --fail-on-gate "Release gate"

You can pass all instead of a gate name, and combine --fail-on-gate with --fail-on <severity>. Exceptions are part of the same flow: a developer requests an exception with a business justification and an expiry date, approvers decide, and the decision is recorded in the audit trail.

For a deeper comparison of what each control does and where it runs, see policies vs gates vs guardrails in Safeguard, and for the broader governance model, security governance in Safeguard.

The audit log: what is recorded, where it goes and how long it stays

When a security reviewer asks "can you prove who changed what," the answer is the audit log. Safeguard's RBAC page says every action that mutates state is recorded with five elements:

The docs describe the log as append-only and cryptographically chained, and retained for the period your tenancy allows: 90 days by default, configurable up to seven years for Enterprise. That is the RBAC page's figure for the tenant audit log. The Portal audit page, covered below, documents a different set of defaults for its own logs, so ask Safeguard which retention applies to the log you will rely on. The docs show an illustrative entry for a role change from Viewer to Security Engineer on a payments team, with actor, action, before, after, target, timestamp, IP, session, client and a reason linked to an exception. They are careful to say the field names illustrate the shape, not a fixed export schema, so do not build a parser against that example without checking a real export.

Deprovisioned users' actions stay in the log permanently, and break-glass actions are labelled separately. The Organization and User Management page lists logins, project access, setting changes (old and new value) and role changes, viewable under Settings, Audit Log with filters by user, action and date.

Other audit records you should know about

• Guard's audit trail records each allow, deny or monitor decision Guard makes on agent and MCP traffic. It answers what Guard did with a request, not who changed Safeguard.
• Portal audit trails record SBOM, access and administrative activity with actor, action, resource, IP address, user agent and result, exportable as CSV, JSON or PDF. The Portal page lists its own retention defaults (two years for access logs, seven years for administrative and security events, configurable for Enterprise).
• Security activity under Settings in ESSCM, where a workspace has it, shows each user their own events and shows tenant admins everyone's, including key creation and revocation and member deactivation. Keys themselves are never recorded, and refused actions are recorded as failures.

Streaming the audit log to your SIEM

The RBAC page lists four ways to stream the audit log in real time: a webhook with JSON per event, scheduled batch export to object storage, OpenTelemetry logs, and a SIEM HTTP event collector. For webhooks, you subscribe to the audit.action event on the Webhooks page. Webhook deliveries are signed with an HMAC SHA-256 signature in the X-Safeguard-Signature header, carry an idempotent event ID and an attempt counter, and are retried with a dead letter queue. Verify the signature with your signing secret before you trust a payload, and de-duplicate on the event ID.

A practical rule: stream from day one of the pilot, not from go-live. The first weeks are when roles and groups change most, and that history is exactly what an auditor will ask about later.

A phased rollout plan

Everything above comes together in a plan. The phases below follow the order the controls depend on each other: structure, then identity, then access, then enforcement. Durations depend on your organization, so they are left out; what matters is the exit criterion for each phase.

Phase 1 protects the admins. Make sure at least two tenant admins can get in if SSO fails before you turn on stricter settings. Phase 4 is not optional: Warn and Notify let teams see what a policy would catch, clear the backlog (with autonomous remediation pull requests if you have switched that on) and agree on exceptions before a release depends on it. Phase 6 removes the safety net, so test deprovisioning end to end first, including the credentials it does not touch.

For the repository side of phase 3, our guide to onboarding a new repository to Safeguard walks through the steps, and the ESSCM enterprise guide covers the wider platform.

Where your data lives during all this

Regulated buyers usually ask about hosting in the same review. Safeguard runs as multi-tenant SaaS in US, EU (Frankfurt, Germany) and Gov regions, as a private VPC or dedicated tenancy, on-prem, or fully air-gapped, with tenant-based data isolation for enterprises. Our post on multi-tenant isolation architecture covers that side.

Answering the identity section of a security questionnaire

Enterprise security reviews ask the same identity questions every time. These answers are grounded in Safeguard's documentation, so a reviewer can verify them.

Common mistakes

Putting the identity provider's Entity ID in both places. SAML has two Entity IDs. The provider's goes into Safeguard; Safeguard's goes into the provider. Mixing them up makes the provider reject every request.

Relying on the Name ID for email. Safeguard reads the user's email from an attribute named email. Without it, logins fail even when everything else looks right.

Switching on auto-link before checking email hygiene. JIT auto-link joins an SSO identity to an existing password account by email. If your directory recycles addresses, a new hire could inherit a former employee's account. The default, reject conflicts, exists for this reason.

Turning off password login before testing the outage path. If the identity provider fails and nobody has tested Request access or break-glass, the whole security team can be locked out at once.

Assuming deprovisioning cleans up automation. It revokes sessions and user API keys. It does not touch service tokens, workload identities or organization secret keys. Add them to the offboarding runbook.

Mapping groups to role names from the wrong surface. Core RBAC, organization management and Portal each describe their own role names.

Going straight to Block. Gates that block on day one train developers to request exceptions by reflex. Start with Warn and Notify.

Starting audit streaming at go-live. The pilot is when roles change most. Stream from the first day.

FAQ

Does Safeguard support SAML SSO?

Yes. Safeguard supports SAML 2.0 alongside OpenID Connect and Google, Microsoft and GitHub login. You configure providers under Settings, Authentication, Single Sign-On as a tenant Admin or Owner, and the web application docs note that SSO is supported for Enterprise tenants.

Does Safeguard support SCIM provisioning?

Safeguard's RBAC documentation lists SCIM 2.0 for automated provisioning and deprovisioning, triggered by your identity provider pushing events to Safeguard. SSO and SCIM are listed on the Enterprise tier. Confirm the SCIM endpoint and token setup with Safeguard during onboarding, because the docs pages we reviewed do not publish them.

What happens to a user's access when they leave?

On deprovisioning, by SCIM or manually, Safeguard revokes all sessions and all of the user's API keys, reassigns their pending approvals to their team, and keeps their past actions in the audit log. Service tokens, workload identities and organization secret keys are not affected and must be revoked separately.

Can we require passkeys or hardware keys?

Safeguard supports WebAuthn and passkeys (preferred), FIDO2 hardware keys and TOTP, with phone and SMS factors off by default. Policies can require a specific multi-factor level for specific actions, such as a passkey re-authentication before a sensitive change.

Can we map identity provider groups to Safeguard roles?

Yes. The organization management docs describe group mappings under Settings, SSO, Group Mappings, each mapping a group to a role and a set of organizations. Safeguard documents more than one role vocabulary by surface, so confirm the names your tenant shows first.

How do we keep one business unit from seeing another's findings?

Put each business unit in its own organization within the tenant, scope roles to that organization or to teams inside it, and use per-asset label scopes for anyone who needs narrow cross-unit access.

Is the Safeguard audit log tamper-evident?

Safeguard's docs describe it as append-only and cryptographically chained, retained 90 days by default and configurable up to seven years for Enterprise, and streamable to your SIEM.

What if our identity provider goes down?

Users choose Request access on the login screen, which emails every Tenant Admin. Password reset is a fallback if password login is still on; otherwise recovery goes through Safeguard support.

Which plan includes SSO and RBAC?

Safeguard's pricing notes list RBAC and SSO with shared policies and gates on the Team tier, and SSO and SCIM with a dedicated technical account manager on the Enterprise tier. Check the live pricing page for current details.

From rollout to remediation

Identity and access controls decide who can change your security program, but the program still exists to get vulnerable dependencies out of the software those people ship. Once the rollout is done, the same organizations, roles and gates govern how fixes move from a finding to a merged pull request.

Fix it without waiting for upstream

Whatever the vulnerability, most of the risk sits in two gaps. The first is the time between a fix being published and that fix actually running in your production builds. The second, and worse, is the time before any fix exists at all, while a maintainer works out a patch and a release schedule. Waiting through both gaps is a habit, not a requirement. Safeguard gives teams three ways to close them.

1. Autonomous remediation: pull requests, not tickets

When a fixed version exists, Safeguard's Griffin models open a tested, policy gated pull request that moves the affected dependency to the safe version. You can run it on one repository or in bulk across every project that carries the vulnerable version. Remediation categories include dependencies, licenses, security posture and findings, and each one is set separately. Reachability analysis ranks the vulnerable code paths your application actually calls first, so the first pull requests you merge are the ones that matter most. Autonomous remediation ships switched off, with every category set to Manual, so your team decides how much runs on its own and what still needs a human approval.

2. Gold Open Source: the safe version in seconds, free

gold.safeguard.sh is free and needs no login. Search any CVE or package to see affected and fixed versions, CVSS, EPSS, CISA KEV status and a recommended safe version, or use the "Am I affected?" checker. The same data is available through a free read API, README status badges and RSS threat feeds.

3. Gold Registry: start from components that are already fixed

Gold Registry provides hardened, drop in replacements for upstream packages and container images. Every Gold artifact is held continuously to zero exploitable critical or high CVEs and a completed license check, with signed build provenance (signed with Safeguard's key and verifiable with cosign, SLSA Build Level 3 as the design target) and a public evidence page you can hand to an auditor. An artifact loses its Gold badge if it regresses. Teams can point their own package directory at the registry so hardened equivalents resolve without changing how developers install anything.

When upstream has no fix yet, or will not ship one, Safeguard first works to get the fix accepted upstream. If the issue is severe or upstream will not move, Safeguard builds a fork, fixes the vulnerability there and publishes a hardened Gold build, so you are not stuck on a maintainer's release schedule. You can also request a hardened, compatibility tested build of a specific package. Ask which packages it covers before you plan around it.

One honest limit: when the vulnerable code lives in a vendor appliance, a hosted service or an operating system runtime you do not build yourself, the fix still has to come from that vendor or distribution. The steps above apply to the open source dependencies and container images you build and ship, which is where most teams carry the largest and least tracked share of their exposure.

See how Safeguard would help

These demos show surfaces your developers and assistants will use once the rollout is in place.

The first demo connects Claude to the Safeguard MCP server with OAuth and shows how you choose which tools Claude can use. In an enterprise rollout, this is the developer-side view of the tool gating that a platform owner controls per tenant.

Click through it at your own pace, or open it full screen.

The second demo is a real Safeguard CLI session. A developer asks the assistant to fix a lodash CVE; it reads the finding and advisory, asks before any command that changes something, updates the dependency, runs the install and tests with approval, prints a summary and pushes nothing. It is the flow a developer in a newly onboarded team would use for a first fix.

Click through it at your own pace, or open it full screen.

The third demo sets up the local runner on your own machine, approves it with its device code, then scans from the terminal. For teams that will not grant repository access during a pilot, this is the way to start while identity and roles are being finalized.

Click through it at your own pace, or open it full screen.

To try Safeguard yourself, download the apps or start with the CLI documentation.

Quick check

Sources

• Safeguard docs: SSO Authentication
• Safeguard docs: SAML 2.0
• Safeguard docs: OpenID Connect
• Safeguard docs: URLs and Endpoints
• Safeguard docs: Provisioning Policy
• Safeguard docs: Testing and Troubleshooting
• Safeguard docs: RBAC, Teams and Organizations
• Safeguard docs: Organization and User Management
• Safeguard docs: Portal User Roles
• Safeguard docs: Portal Audit Trails
• Safeguard docs: Web Application
• Safeguard docs: Account Recovery and Keys
• Safeguard docs: API Platform team and access
• Safeguard docs: MCP tool availability and gating
• Safeguard docs: Policies and Gates
• Safeguard docs: Policy outcomes and actions
• Safeguard docs: Webhooks and Events
• OASIS: Security Assertion Markup Language (SAML) V2.0 Technical Overview
• OASIS: Assertions and Protocols for SAML V2.0 (core)
• OpenID Foundation: OpenID Connect Core 1.0
• IETF RFC 7643: SCIM Core Schema
• IETF RFC 7644: SCIM Protocol
• W3C: Web Authentication Level 3
• NIST SP 800-63B-4: Authentication and Authenticator Management
• NIST CSRC: SP 800-63B-4 publication record
• IETF RFC 6238: TOTP

Last reviewed: 26 October 2026.