Managed identity
Supported P360 applications integrate with P360 Gate for signed-in entry, while the application retains responsibility for its own role checks.
Security approach · Scope before claims
Security & data handling
Controls you can inspect, with limits we will state plainly.
PUX Devs products handle operational records that deserve careful identity, authorization, audit and recovery design. The exact controls differ by product and client deployment, so we document the verified state instead of applying one blanket promise.
Deployment control mapScope-specific
IdentityWho
AuthorityMay do what
EvidenceWhat happened
01AuthenticateEstablish a signed identity
02AuthorizeCheck role and ownership
03ValidateEnforce workflow rules
04RecordRetain material evidence
Control model
Protect the lifecycle, not just the login page.
Identity matters, but so do server-side authority, data ownership, retry behaviour, auditability and the recovery path after failure.
Server-side authorization
Sensitive routes are designed to verify role, object ownership or workflow authority again on the server.
Data minimisation
Interfaces should expose the fields needed by the role and avoid turning encrypted or sealed records into broad dashboard data.
Audit evidence
Material actions in supported products write actor, time and change context, with stronger database protection in workflows that require it.
Failure made explicit
Integrations and queued work are designed with visible pending or failed states rather than a success message after a partial failure.
Recovery by deployment
Backup destination, retention, restore verification and recovery ownership are confirmed for the actual service scope.
Vendor review
Questions we expect a serious buyer to ask.
A security conversation should end with evidence and responsibilities, not only a feature checklist.
01 · Identity
How is access granted and removed?
Review the provider, groups, roles, session model and leaver path for the chosen products.
02 · Data
Where does the record live?
Identify the application database, uploaded files, deployment boundary, retention and export path.
03 · Operations
What happens when a dependency fails?
Inspect retry, deduplication, user messaging, logs and the owner of manual recovery.
04 · Recovery
What has actually been restored?
Separate a backup job from documented restore verification and any remaining offsite dependency.
Scope and honesty
What this website does not claim.
Good security communication avoids absolute promises and distinguishes implemented code, configured deployment and verified operating evidence.
Not “unhackable”
No serious system can promise that. We design defence in depth and discuss residual risk.
No blanket certification claim
No external certification or compliance attestation is implied unless it is named with current evidence.
No universal backup promise
Some products have local restore verification while offsite activation remains a separate deployment item.
No one-size tenant claim
A dedicated client deployment and a proven shared multi-tenant model are different architectures.
Security review
Reviewing PUX Devs as a vendor?
Tell us which product, data and workflow are in scope. We can walk through architecture, authority boundaries, recovery responsibilities and the evidence available for that deployment.