Security and hardening guide

This guide is for the people who set up and run Final Frame for their organisation: IT and security teams, and the Org admins who manage users. It says how Final Frame protects your content, what you control, and how to configure it for least privilege.

It is our application configuration guideline under the MPA Content Security Best Practices (TS-1.17 and TS-1.18). We review it at least once a year and whenever a component is added, upgraded or removed. Last reviewed: October 2026.

1. How Final Frame is built

Generative AI features run on Google Vertex AI. One optional image model runs on fal.ai. Our AI use statement, with what each feature sends and where, is available on request.

2. Who is responsible for what

3. Sign-in and MFA

Accounts are by invitation only. There is no public sign-up.

Option A: your company's single sign-on (recommended)

Use your own identity provider (Okta, Microsoft Entra ID, Google Workspace, or any SAML or OIDC provider). Your MFA, device and network policies then apply to Final Frame.

1. In Final Frame, open Organisation settings, then the Sign-in tab. You need the Admin role.
2. Under Company domains, add your email domain and follow the steps to prove you own it.
3. Under Company sign-in, choose Set up. This opens a setup page for your organisation only. Your IT admin configures the connection there.
4. Test with one user, then tell your users. Anyone with an email at your domain is sent to your identity provider after typing their email.

Notes:

• Single sign-on proves who a person is. It does not grant access. A person still needs a membership in your organisation, which your admin creates by invitation.
• Your domain's sign-in applies only to people with your domain's email. A guest from another company signs in with their own company's method.
• Enforce MFA in your identity provider. Final Frame does not ask for a second factor on top of a single sign-on.

Option B: email, password and authenticator app

For people without single sign-on:

• A password, then a six-digit code from an authenticator app (Google Authenticator, 1Password, Authy or similar) at every sign-in. The app is enrolled with a QR code at the first sign-in.
• Keep recovery codes in a password manager.
• Use a long, unique password. A password manager makes this easy.

Passkeys

A person can add a passkey (Touch ID, Face ID, Windows Hello or a security key) from their profile after signing in. A passkey counts as both factors.

Social sign-in

Google, Microsoft and Apple sign-in may appear on the sign-in screen. With these, the provider's own second factor applies and Final Frame does not add one. If your policy requires MFA you control, use Option A.

4. Roles and least privilege

Access comes only from a membership: a person, your organisation, a scope, and a role.

Scope is your whole organisation, one Group inside it, or one Project. Access granted on a Group applies to every Group and Project below it. Grant at the narrowest scope that works.

Recommendations:

• Keep Admins to two or three named people. Never use a shared admin account.
• Give partners and freelancers Viewer on the one Project they work on.
• Give Editor on a Group or Project, rather than on the whole organisation, where you can.
• Review your Users list every quarter. Remove anyone who has left or no longer needs access.
• Removing a membership ends that person's access to your organisation at their next request.

5. Sessions

These values are the same for every organisation and cannot be changed per organisation today. If you need shorter sessions, apply them in your identity provider for single sign-on users.

6. Network and IP restrictions

Final Frame does not offer IP allowlisting today. To restrict where people can sign in from, use your identity provider's own controls with Option A (for example Okta network zones or Entra ID Conditional Access).

All traffic uses HTTPS with HSTS. Plain HTTP redirects to HTTPS.

7. Content transfer

• Files go straight between your browser or the Mac app and your organisation's storage, with signed links that work for one file, for a short time (15 minutes by default). Files never pass through our application servers.
• An upload link is fixed to one file, one content type and a size range.
• Your organisation's files are in your organisation's own bucket, encrypted with your organisation's own key. No other organisation's link can reach them.
• Treat a download link like a password while it is valid. Do not paste it into chat or email.
• Uploads, removals and deliveries are recorded in the audit trail.

Project inbox

Each project can have an email address. Mail from unknown senders is held for an Editor or Admin to let in. Attachments are virus scanned before anyone can open them. A file that is infected, or cannot be scanned, stays blocked.

8. The Mac app

• Download it only from the Download page on our website.
• It is signed with our Apple Developer ID and notarised by Apple. macOS checks this on first launch.
• It keeps a journal of transfer progress so a transfer can resume. The journal holds no file contents.

9. Support access

To answer a support request, a Final Frame administrator can view the app as one of your users. This access:

• is started only for a support request or a security investigation,
• lasts at most 30 minutes,
• shows a banner while it is active,
• is recorded in your organisation's audit trail as impersonation.started and impersonation.ended, naming the Final Frame administrator.

Admins can review these entries in the audit trail.

10. Audit trail

Admins (permission audit.view) can read who did what in each project: uploads, receipts, removals, status changes, deliveries, handoffs, invitations, role changes and support access. Entries cannot be edited. They are deleted only when your organisation is permanently deleted at the end of your contract. Ask us for an export before then.

11. API keys

Status: in development for the v1 partner API. When available:

• Admins create organisation keys in Organisation settings, choosing the permissions each key holds. A key can never hold more than the person who creates it.
• A key is shown once, at creation. Store it in a secrets manager, never in source code, a ticket or a chat.
• Create one key per integration, with only the permissions it needs, so one can be revoked without touching the others.
• Check each key's last-used time every quarter. Revoke keys that are unused.
• Revoke at once if a key may have been exposed. Personal keys are revoked automatically when the person's membership ends.

12. Webhooks

Status: in development for the v1 partner API. When available, Final Frame will sign each webhook under the Standard Webhooks specification. Your endpoint should:

• accept HTTPS only,
• verify the signature on every request using your endpoint's signing secret, and reject anything that fails,
• reject requests whose timestamp is more than five minutes old,
• treat the webhook-id as an idempotency key: the same event can arrive more than once,
• answer quickly with a 2xx and do the work afterwards,
• rotate the signing secret if it may have been exposed.

13. Your checklist

• [ ] Single sign-on set up for your domain, with MFA enforced in your identity provider
• [ ] Two or three named Admins, no shared accounts
• [ ] Partners and freelancers scoped to single Projects, as Viewers where possible
• [ ] Quarterly review of your Users list
• [ ] Leavers removed the day they leave, or automatically through your identity provider
• [ ] A security contact for your organisation given to Final Frame
• [ ] Your own copy of original masters kept

14. Reporting a security issue

Email security@final-frame.com. We acknowledge within one working day. Please do not test against another organisation's data.