Hardening guide
Secure Configuration Guidance
Recommended hardening settings for organizations deploying Trust Swiftly for Government. These recommendations complement the platform's secure defaults; apply them during initial tenant configuration and re-verify them at your periodic access reviews.
Machine-readable: secure-configuration.json. This page is rendered from that same file. Last updated: 2026-08-18.
Administrative identity and access
- Connect single sign-on (SSO) to your identity provider and enforce it for every administrative user. Centralizing sign-in at your IdP applies your organization's lockout, session, and conditional-access policies to platform access, and lets you revoke access in one place.
- Enforce multi-factor authentication for all users, with no exempted accounts. Enforce MFA at the tenant level so newly provisioned operators inherit the requirement automatically.
- Prefer phishing-resistant passkeys; for federal deployments use FIPS 140-validated hardware authenticators such as the YubiKey FIPS series. Hardware-bound passkeys resist phishing and credential replay, consistent with federal zero-trust guidance on phishing-resistant MFA.
- Enable SCIM provisioning from your identity provider. Joiner, mover, and leaver events in your directory then create, update, and deprovision platform accounts automatically — separated staff lose access without a manual step.
- Assign least-privilege roles scoped to job function. Restrict each role to what the job requires — for example, reviewers who work the verification queue do not need settings or billing administration. Keep the administrator role to the minimum set of operators and review assignments quarterly.
- Restrict administrative access to corporate egress IPs with an IP allowlist. An allowlist confines admin sessions to your managed network paths (VPN or corporate egress), so stolen credentials alone are not sufficient from an arbitrary network.
- Limit platform access to staff who need it, and remove dormant accounts. Disable accounts unused beyond your dormancy threshold and remove access immediately at separation — SCIM automates the latter.
API and integration security
- Issue limited-permission API tokens scoped to what each integration needs. Create one token per integration with the fewest abilities that work; never share a token across systems, and never embed tokens in client-side code.
- Rotate API tokens periodically, and immediately on staff changes or suspected exposure. Scheduled rotation bounds the life of any token that leaks outside your control.
- Deliver webhooks only to HTTPS endpoints you control, and authenticate each payload at your receiver before acting on it. Validate that inbound events genuinely originate from the platform before your systems act on verification outcomes.
- Keep test and production configurations separate, and never send real personal data through test workflows. Separate tenants or clearly separated workflows prevent test integrations from touching production identity evidence.
Data minimization and retention
- Set the shortest data retention window your records schedule allows — configurable from 1 to 120 days. Verification evidence is deleted when the window expires; a shorter window means less personal data at rest at any moment.
- Enable only the verification methods your risk level requires. Tailor workflows per risk level and collect the minimum evidence that satisfies the assurance requirement — reserve higher-assurance methods for the populations that need them.
- Apply legal hold narrowly, and remove it when the matter closes. A hold suspends deletion for the named user only; a hold left in place after the matter ends becomes unmanaged retention.
Monitoring, alerting, and audit
- Enable SIEM export and logging into your security tooling. Streaming platform events to your SIEM puts verification activity in the same detection and retention pipeline as the rest of your estate.
- Enable country restriction alerts routed to your security team. Access or verification activity from unexpected geographies is surfaced to your team for review.
- Enable device velocity rules. Velocity rules flag the same device appearing across many identities in a short window — a common pattern in organized fraud.
- Treat fraud and risk signals as review telemetry, not automatic blocks. Route signals to your review workflow so a trained reviewer decides the outcome; silent auto-blocking hides fraud patterns from your team and penalizes false positives.
- Review administrative audit logs periodically. Include role and permission changes, settings changes, and data exports in your periodic access review.
Settings are configured by your tenant administrators in the admin console unless noted. For configuration assistance, contact the Security contact listed on this trust center.