Loading...
Skip to main content
Security

Controlled access and policy-led workflows for operational teams

PTTHex security conversations focus on who should communicate, what context should be visible, how users and devices are approved, how channels are governed, and what needs review before rollout.

Controlled access

Plan access around customer roles, users, devices, branches, departments, groups, channels, and license scope.

Role-aware workflows

Give owners, security admins, dispatchers, branch or department admins, auditors, and operators paths that match their duties.

Privacy-aware context

Discuss location, telemetry, monitoring, and dispatch workflows only where policy, permissions, and privacy review support them.

Audit-ready operations

Support reviewable activity, approval, policy, monitoring, and maintenance workflows without exposing sensitive payload details.

How the security model works

PTTHex is built to deny by default and open access only when policy allows it. These are the controls the platform is designed around.

Fail-closed by default

Access is denied unless a rule allows it. If a permission, approval, or policy check does not pass, the action stops rather than falling back to open access.

Login only, no public signup

The panels offer sign-in only. Field users cannot create their own account. Their request goes to an authorised manager in your organisation, who approves it before any access is granted.

Multi-factor step-up

Sensitive actions can require a second factor. Optional multi-factor sign-in supports authenticator apps, passkeys and security keys, and recovery codes, all served from your own deployment.

Role-based permissions

New roles start with no authority and are granted only what they need. When rules conflict, an explicit deny always wins, so access stays intentional as your team grows.

Approved devices only

Every device has to be approved before it can be used. Device identifiers are kept as a one-way hash rather than raw values, so a device can be recognized without storing its fingerprint in the clear.

Encrypted transport and audit trail

Traffic is encrypted in transit, and admin actions are written to an immutable, redacted audit trail so approvals, policy changes, and access decisions can be reviewed later.

Security starts with the rollout model

A field communication platform should be reviewed around customer responsibilities as well as product capabilities. Device ownership, channel governance, user onboarding, monitoring visibility, and privacy expectations all matter.

PTTHex denies access by default. Every user and device is approved on your side, management sign-in has no public signup, the runtime stays on your infrastructure, activity data is stored under your control, status views are limited to what a role may see, and a failed check blocks access rather than allowing it. Requirements specific to your industry or jurisdiction are worth reviewing with us directly.

Bring the right questions

  • Who should join, speak, listen, or manage each channel?
  • Which devices and users need approval?
  • Where are location, telemetry, and monitoring useful and appropriate?
  • What audit, retention, and support expectations apply after launch?
Plan a controlled rollout Review deployment planning
Privacy by design

Keep sensitive data minimal and under your control

PTTHex is built to collect less and keep it close. Location and monitoring workflows are used only where policy and permissions allow, and personal data is redacted where it is not needed.

  • Team positions on the map are redacted and grouped rather than shown as raw coordinates, and people outside a user's scope cannot see their location.
  • Location sharing is consent-based and can be paused by the person sharing it.
  • Translation, captions, and transcription are consent-gated, and raw audio is not retained.
  • Message recording is off by default and turns on only with consent, a role, retention limits, and an audit record.

Self-hosted, so data stays with you

PTTHex runs on your own server. After deployment there is no external service in the loop: the sign-in puzzle, the maps, and the runtime are all local, so customer data does not leave your environment.

  • No outside SaaS, hosted analytics, or third-party sign-in check after go-live.
  • Maps and tiles are served locally, with no paid or external map provider.
  • Access and capacity are set by a licence bound to your server, and your managers can tighten it but never widen it.
See how it is deployed