People and identity
Assign individual accounts, roles and an accountable organisation owner. Review membership, pending invitations, MFA and recovery paths regularly. Configure supported OIDC SSO with the provider and exact claim mapping used by the deployment. Provider configuration and a successful sign-in are separate checks; test access removal and role boundaries as well.
Single sign-on and SCIM
- Only the Super Admin changes the SSO domain or identity provider. Changing the provider also needs the Super Admin's password and, where one is set up, an authenticator code.
- Opening FDIE from your identity provider's app portal shows a Continue page first; the sign-in starts when the person chooses Continue.
- With Google Workspace, FDIE accepts only accounts that your organisation's Workspace manages.
- SCIM 2.0: the base URL is https://fdie.magdox.io/api/scim/v2. The Super Admin creates the SCIM token under Settings, Single sign-on, with their password and, where one is set up, an authenticator code; it is shown once and can be revoked there.
- SCIM sees only people on your verified domain and never changes the Super Admin. New people join with the organisation's SSO join role (analyst or viewer). Deactivating or deleting a person removes their membership, sessions, API keys for the organisation and SSO link.
Intelligence and monitoring
Hosted deployments refresh vulnerability and prioritisation data on configured schedules and can recheck retained firmware. These feeds are not real time. Read the feed timestamp and assessment context before making a release decision. Offline deployments need approved transfers; old feed data remains old even when an analysis completes successfully.
Notifications and integrations
- Configure email and supported Slack, Teams or webhook destinations only for approved recipients.
- Treat report attachments and webhook payloads as external disclosures, even when firmware itself is not transmitted.
- Use documented APIs and scoped credentials; keep tokens out of browser screenshots and public CI logs.
- Revoke unused access and rotate compromised credentials. The marketing website does not accept firmware or API credentials.
Billing and capacity
Self-service administrators use Settings → Billing to review the money-back guarantee, renewals, seats, retained storage and monthly analyses. Adding storage does not add analysis allowance; annual billing does not make that allowance annual. On-premises capacity and licence renewal follow the contract instead of hosted checkout.
Retention and exports
Assign an owner for retained images and report access. Review product-specific retention, deletion requests and backup expiry before promising a customer an erasure date. Export reviewed evidence while access is available; keep it under your own retention controls. A website migration does not transfer or delete application data.
A routine operating review
| Review | What to inspect | Follow-up |
|---|---|---|
| Access | Current members, roles, invitations and identity configuration | Remove obsolete access and verify recovery ownership |
| Analysis | Queue health, failed stages and incomplete assessments | Investigate failures and communicate the effect on release evidence |
| Intelligence | Available feed age and update results | Refresh through the approved online or offline process |
| Capacity | Retained firmware, scratch storage and subscribed allowances | Plan headroom before another upload or analysis batch |
| Recovery | Backup completion and the last representative restore exercise | Resolve missing evidence or failed recovery steps |
Respond to a failed analysis
Start from the image's processing and coverage record. Identify the failed stage, keep any usable partial results and check storage or resource pressure before retrying. If support is needed, send the product version and redacted failure context first; arrange a secure channel before transferring firmware, secrets or detailed artifacts.