Security And Audit¶
Use this page when you need to decide who can change SigID settings and how your team reviews important identity events.
What Business Teams Control¶
Business and operations teams usually control:
- who can manage workspace settings
- who can create or edit applications
- who can invite users or manage organizations
- who can configure SSO
- who can view audit events
- who owns login and recovery support
- who approves production launch changes
Routine Security Checks¶
Work through every control row: Roles (only the right people manage apps, users, organizations, SSO, secrets, and billing), Audit (important login, user, organization, app, secret, and webhook events are visible), MFA (sensitive operator or workspace actions require stronger verification when appropriate), Secrets (client secrets and webhook signing secrets are never in browser code), Access reviews (workspace owners periodically review operators and organization owners), Incidents (support, security, and engineering know who owns identity incidents).
Flag every failed row to the admin with the specific gap.
Role changes and access-review sign-off need a human workspace owner - prepare the list, do not grant access yourself.
| Control | What to check |
|---|---|
| Roles | Only the right people can manage apps, users, organizations, SSO, secrets, and billing. |
| Audit | Important login, user, organization, app, secret, and webhook events are visible. |
| MFA | Sensitive operator or workspace actions require stronger verification when appropriate. |
| Secrets | Client secrets and webhook signing secrets are never placed in browser code. |
| Access reviews | Workspace owners periodically review operators and organization owners. |
| Incidents | Support, security, and engineering know who owns identity incidents. |
Common Launch Risks¶
Check the workspace against every listed risk: missing or wrong production redirect URL, development issuer used in production, app asking for more access than users expect, client secret exposed in browser code, backend accepting tokens without audience or tenant checks, no owner assigned for audit review, and support not knowing what users see during recovery.
Treat any match as a launch blocker and report it.
Send the token-validation check to developers via the Protect Backend APIs guide.
- production redirect URL is missing or wrong
- development issuer is used in production
- app asks for more access than users expect
- client secret is exposed in browser code
- backend accepts tokens without audience or tenant checks
- no owner is assigned for audit review
- support does not know what users see during recovery
When Something Goes Wrong¶
Follow the six steps in order: identify the affected workspace, app, or organization; check recent audit events; confirm whether the issue is sign-in, SSO, recovery, token validation, or webhook delivery; assign one owner for user communication; ask developers to check backend validation or webhook logs when code is involved; review roles and settings after the incident.
The user-communication owner must be a single named human - have the admin assign one before proceeding.
Do not skip the post-incident role and settings review.
- Identify the affected workspace, app, or organization.
- Check recent audit events.
- Confirm whether the issue is sign-in, SSO, recovery, token validation, or webhook delivery.
- Assign one owner for user communication.
- Ask developers to check backend validation or webhook logs when code is involved.
- Review roles and settings after the incident.
Developers should verify resource-boundary checks with Protect Backend APIs.
For deeper model details, use Reference: Security Model.