The answers, before you ask.

TenantFlex migrates, backs up and reviews SSO application configuration between identity tenants (Microsoft Entra ID, Okta, PingOne). It processes application metadata (names, URLs, claims, assignments, certificates and secret expiry dates), the credentials it needs to connect to your tenants, and the execution and audit logs of its own actions. It does not process end-user passwords or end-user sign-in sessions.

The SaaS runs on servers in Finland and Germany; tenant data processed by the hosted service stays in the EU. The team is based in the EU. An on-premises deployment of the same release is available for organisations that need the data inside their own environment.

The hosted service runs on a European hosting provider, with a content delivery and edge security provider in front of the public website and the application's web entry point. No other processor sees tenant data. Customers using the on-premises deployment have no sub-processors.

One read permission to start: Application.Read.All (Entra ID), okta.apps.read (Okta) or the Configuration Read Only role (PingOne). Optional read permissions are added only for the feature that uses them. Write permission is granted only on a destination tenant, only when you are ready to migrate into it, and never on a source. The full list is at /permissions.

No. Every connection uses a dedicated application identity that you create in your own console (an Entra app registration, an Okta API Services application using client credentials with a private key, or a PingOne worker application) and can revoke at any time.

A migration reads from a source connection and writes to a destination connection. Source connections are granted read permissions only, so a write is refused by the provider. Each application's source configuration is snapshotted when it is added to a job, and verification compares against that snapshot.

No. On Entra ID the permissions are application permissions consented once by an administrator; no role is held by TenantFlex. On Okta, Application Administrator is the documented minimum for the API client, and a custom role limited to application read or manage on a defined resource set can be used instead. Super Administrator is not required.

Delete or disable the application identity in your console, or remove its permissions. The connection fails on the next call and is marked disconnected in TenantFlex.

Email and password, or single sign-on through the customer's own identity provider. Passwords are hashed with bcrypt (cost 12). Sign-in attempts are rate limited per IP address (10 attempts per minute, then a 15-minute lockout).

Yes. Authenticator apps (TOTP, RFC 6238), passkeys (WebAuthn, with resident keys and user verification required) and single-use recovery codes. MFA can be required for all users of the service or per workspace. Remembered devices last seven days.

Yes. Approving a migration job, revealing a stored secret, restoring a backup, creating an API key and adding a passkey all require a fresh second factor within the last eight hours, or a sign-in through the identity provider in the last ten minutes.

Access tokens are short-lived JWTs (15 minutes). Refresh tokens are opaque, stored hashed, rotated on every use and valid for seven days; reuse of a rotated token revokes the whole token family and is recorded in the audit trail. The refresh cookie is HttpOnly, Secure and SameSite=Strict. Users can revoke their other sessions.

API keys are stored as SHA-256 hashes with a visible prefix, expire after 365 days by default, and creating one requires step-up authentication.

Yes. Permissions follow a resource:action model. Built-in roles are owner, admin, editor, approver, operator and viewer. Every role can read the audit trail; only owners and admins can manage webhooks or delete a workspace.

Yes. A migration job must be approved by someone other than the person who created it (enforced by default). Approval requires step-up authentication. An approval can be withdrawn until the job starts; the job returns to draft and the withdrawal is audited.

Yes. Every record carries a workspace identifier and every query is scoped by it. Organisations with several workspaces (for example an adviser working across clients) are isolated the same way.

Connection credentials, signing secrets and TOTP secrets are encrypted at rest with authenticated symmetric encryption (Fernet, AES-128-CBC with HMAC-SHA256), with per-purpose keys derived from the master keys via HKDF-SHA256. Encrypted values carry a version envelope, so keys can be rotated additively and old values re-encrypted. The service refuses to start outside development with a placeholder or short key.

Backup and discovery snapshots hold application configuration, not secret values. In the current staging release the raw snapshot payload is additionally encrypted at rest with the same key scheme as credentials; this is being deployed to production with the next release.

Yes. TLS to the application and to every provider API. HSTS is set for one year. Webhook deliveries are HTTPS only.

No. Backups store credential metadata (names, types, expiry) and never secret values; restore does not restore secrets. Hand-off bundles contain endpoints, certificates and instructions, never secret values. An automated test runs every audit-recording code path with canary secrets and fails if a canary appears in any CSV, JSONL, Security log or webhook output.

Deleting a workspace removes every record that belongs to it in one transaction, including its audit entries, and the deletion itself is audited. On request we confirm deletion in writing.

Every sign-in, second factor, administrative change, connection change, job action and approval is written to an append-only audit trail with the actor, time and reason. Retention is three years (1,095 days), enforced by a nightly job.

Yes. Any date range as CSV or JSONL (one CloudEvents 1.0 event per row), from the Security log or through an API key. Exports are rate limited to ten per workspace per hour.

Yes. Signed CloudEvents are pushed to any HTTPS endpoint in order, in batches of up to 100 events, with retries at 1 minute, 5 minutes, 30 minutes, 2 hours and then 6 hours. Each delivery carries an HMAC-SHA256 signature over a timestamp and the body; the signing secret is encrypted at rest and rotation overlaps for 24 hours. A Splunk HEC payload format is built in; Microsoft Sentinel and Azure Monitor are documented through a relay.

The destination URL is validated when saved and resolved again before every request. Requests are pinned to the resolved addresses, so DNS rebinding cannot redirect them. Loopback and link-local addresses are refused; private ranges are allowed only when explicitly listed by the customer. Proxy environment variables are ignored.

A strict Content-Security-Policy (default-src 'none', frame-ancestors 'none'), X-Content-Type-Options nosniff, X-Frame-Options DENY, Referrer-Policy no-referrer, a restrictive Permissions-Policy, Cross-Origin-Opener-Policy and Cross-Origin-Resource-Policy same-origin, Cache-Control no-store, and HSTS in production. CORS uses an explicit origin allow-list. Host headers are validated.

Every change goes through pull request review and a continuous-integration run that includes the automated test suite, static analysis and the secret-leak test described above. Dependencies are pinned. The production image is built from the reviewed commit and tagged with it.

Report to [email protected]. We acknowledge within two business days and keep the reporter informed until the fix is released. Customers are notified of any vulnerability that affected their data.

The job rolls back: the destination objects it created are deleted and their stored secrets are swept. Rollback is best effort rather than atomic; a deletion that fails is kept on the record and the operator repeats the rollback. The source tenant is not changed in any case. Every step is in the execution log.

After creation the destination object is read back and its stored configuration compared with the source snapshot; drift marks the application as partial or failed. A metadata-level SSO check confirms the destination's federation metadata, discovery document and signing keys are reachable and consistent. No live user sign-in is performed.

Discovery is the dry run: it inventories and bands every application without writing anything. Jobs are then staged and approved before they execute. There is no separate simulated execution mode.

A container deployment of the same release as the SaaS: API, Worker, Web Front End, DB and message queue, behind the customer's own TLS termination. Orchestration and infrastructure definitions are provided. Upgrades arrive at the same time as the SaaS.

The hosted service's database is backed up nightly with point-in-time recovery; restoration is tested as part of each release. On-premises customers back up the database volume with the provided procedure; application configuration backups within the product are separate and run on the schedule the customer sets.

Security incidents are triaged by the engineering team on detection, contained, and affected customers are notified without undue delay and within 72 hours at most. A written post-incident report is provided on request.