Secure resident tokens
Public survey and building routes use secure tokens rather than exposing internal database identifiers in resident-facing URLs.
Security
Simple for residents.Controlled for teams.
FSEngage is designed to keep public resident journeys separate from protected evidence, engineer information and operational administration.
- Secure token routes
- Private file delivery
- Role-based access
Protection at every handover
Secure tokensResident routes avoid exposing internal record identifiers.
Private evidenceUploads remain outside the public application directory.
Authorised accessRoles and permissions control protected operational views.
Verified integrationsSupported inbound webhooks are checked before processing.
Platform controls
Security is applied across links, sessions, evidence and integrations.
The platform uses layered controls rather than relying on a public QR code or a single login boundary to protect every type of information.Role-based access
Protected administration and engineer functions are limited by authenticated role, organisation and block permissions.
Private evidence storage
Resident and survey photographs are stored outside the public web root and served only through controlled application routes.
Protected sessions
Administrative and engineer access uses hashed credentials and HTTP-only session cookies rather than exposing session material to client scripts.
Separated public data
Public emergency information is deliberately limited to approved telephone fields and does not read private engineer site-pack content.
Verified webhook traffic
Supported inbound messaging webhooks are signature-verified before payload processing when the integration is enabled.
Protected information flow
From public entry point to authorised operational access.
Each stage checks context and permissions before protected records or evidence are made available.- 01
Resolve
The application resolves a secure resident or building token without exposing an internal record ID.
- 02
Validate
The relevant organisation, block, job and feature state are checked before a public journey is shown.
- 03
Protect
Sensitive evidence remains in private storage and is not placed under the application’s public directory.
- 04
Authorise
Office and engineer users receive only the protected information allowed by their role and permissions.
- 05
Deliver
Protected files and operational records are served through application routes with private, no-store response handling where required.
Design principles
Keep the resident journey easy without making private data easy to reach.
Simple does not mean public
Residents get a low-friction scan or link while private operational information remains behind authenticated access.
Different secrets for different purposes
Session signing, Engage token encryption, communication verification and provider credentials are configured separately.
Security follows the workflow
Controls are applied around resident entry, upload handling, staff review, engineer access and optional integrations.
Security FAQs
Clear answers about tokens, uploads and protected access.
A detailed technical and contractual review can be included as part of the implementation and procurement process.Does a public QR code expose a block’s database ID?
No. Resident-facing block routes use secure tokens. Internal database identifiers are not used as the public route key.
Are resident photographs available from a public uploads folder?
No. Evidence is stored below the configured private upload root, outside any public web directory, and is served through protected application routes.
Can a resident QR code reveal engineer access information?
No. Public resident information and private engineer site-pack data are separated. Engineer documents, access details and protected reports require authorised portal access.
How are staff sessions protected?
Administrative and engineer authentication uses hashed passwords and HTTP-only session cookies, with server-side role and permission checks protecting restricted routes.
Are third-party communication credentials stored in the database?
Sensitive provider tokens and secrets are expected to remain in protected server configuration. Administrative status screens expose readiness indicators rather than secret values.
Discuss security in context