Security & Compliance

PTT NZ Limited is a New Zealand-registered telecommunications reseller and Push-to-Talk device platform provider (NZBN 9429053660978), registered office 14 Hazeldean Road, Addington, Christchurch 8024, New Zealand. Security and data protection are treated as a top operational priority across our portal, infrastructure and staff processes.

PTT NZ supplies managed cellular (SIM/eSIM) connectivity and the web portal used to manage it. We are a connectivity provider, not a network hardware vendor or OT systems integrator — see section 2 for how that shapes our standards alignment.

PTT NZ has carried out an internal self-assessment of this portal's technical and organisational controls against three frameworks that are commonly referenced by customers operating industrial, OT or SCADA-connected sites in New Zealand: the New Zealand Information Security Manual (NZISM), the NZ NCSC Minimum Cyber Security Standards, and IEC 62443 (security for industrial automation and control systems).

• Self-assessed, not independently certified. PTT NZ does not currently hold formal third-party certification against NZISM, the NCSC Minimum Cyber Security Standards, or any part of IEC 62443. The statements on this page reflect our own internal assessment of alignment, including open gaps, rather than a certified outcome. Where a contract requires independent certification, we disclose our current status directly and are structuring our controls in preparation for that audit.
• IEC 62443 — scope as a connectivity provider. For customers connecting SCADA/OT sites, PTT NZ's role is limited to providing private, carrier-grade cellular (APN) connectivity between a remote site and the customer's own network — we do not design, supply or operate the customer's control system hardware, SCADA firewalls, field networking equipment, or the zone/conduit architecture of their OT network (IEC 62443-3-2/3-3); that remains the responsibility of the customer's own OT integrator. Our self-assessment instead focuses on the parts of IEC 62443 that apply to us as a service provider — broadly in the spirit of IEC 62443-2-4 organisational requirements such as access control, change management and incident handling for the connectivity service and portal we operate.
• NZISM & NZ NCSC Minimum Cyber Security Standards. Our session-security controls (section 4) are explicitly modelled on NZISM session-management guidance. Measured against the NCSC's ten Minimum Cyber Security Standards, we assess ourselves as substantively aligned on multi-factor authentication, least privilege, patch-response commitments, data recovery (backups) and incident-response planning (sections 5–13). We have not yet implemented centralised/automated unusual-behaviour detection tooling or a scheduled independent penetration-testing programme — these are listed as open gaps in section 8 rather than claimed as met.

Customers, resellers and PTT NZ staff can authenticate using enterprise single sign-on via Microsoft Entra ID (OpenID Connect / OAuth 2.0), in addition to a direct email/password login secured by server-side rate limiting and CAPTCHA.

• SSO is invite-only: a Microsoft identity must match an existing portal user's email address. The portal never auto-creates an account purely from a Microsoft sign-in.
• Existing portal roles and permissions are retained exactly as configured — SSO changes how a user proves their identity, not what they are authorised to do.
• New SSO connections for a customer or reseller organisation enter a pending state and must be reviewed and approved by PTT NZ staff before password login is disabled for that organisation.
• The identity returned by Microsoft at sign-in is cryptographically verified against the email address the user explicitly entered on the login screen before a session is issued — this prevents a browser's cached Microsoft session from signing a user in as a different account.
• An emergency password-based fallback remains available to PTT NZ staff so an organisation is never permanently locked out if its identity provider is unavailable.

The portal applies stricter session controls, aligned with the New Zealand Information Security Manual (NZISM) guidance on session management, to (a) any account or reseller explicitly flagged for government/high-compliance handling, and (b) any account, reseller or staff member currently enforcing single sign-on:

• 15-minute inactivity timeout — a "Still there?" warning is shown roughly one minute before the session would expire from inactivity, with a one-click option to stay signed in; if there is no response, the session is ended automatically and the user is returned to sign in.
• 12-hour maximum session lifetime — regardless of ongoing activity, a strict session cannot be extended past 12 hours before requiring a fresh sign-in (including a fresh Microsoft Entra authentication where SSO is enforced). This is a hard ceiling, not a sliding window.
• Accounts outside this scope retain a standard, longer-lived session suited to normal business use.

Risk-based step-up authentication, Conditional Access policies and identity-provider session lifetimes are configured and governed by each organisation's own Microsoft Entra tenant administrator — these remain the customer's responsibility, consistent with standard Zero Trust/shared-responsibility practice between an application and its identity provider.

Users can enable time-based one-time-passcode (TOTP) two-factor authentication on their portal account in addition to their password. Organisations using Microsoft Entra SSO can additionally enforce MFA at the identity-provider level through their own tenant's Conditional Access policies.

MFA is currently optional, user- or tenant-enabled rather than enforced platform-wide by default for direct email/password accounts — we record this honestly as a partial alignment against the NCSC Minimum Cyber Security Standard on MFA, and can discuss enforcing MFA for a specific customer or contract on request.

The portal enforces the following controls at the network and application layer:

• Least privilege & role segregation — every user (customer, reseller, sub-reseller or staff) is bound to a role that limits which accounts, SIMs and functions they can see or act on; a sub-reseller can only ever view and manage entities beneath them in their own hierarchy (see also section 12).
• Restricted cross-origin access — the API only accepts browser requests from PTT NZ's own configured portal origin(s); requests from any other site are rejected, preventing a malicious third-party page from using a signed-in user's session.
• Login & step-up brute-force protection — sign-in and two-factor verification attempts are rate-limited per account and per source address, with a temporary lockout once a threshold of failed attempts is reached.
• Baseline security response headers — every response sets protective headers (strict content-type handling, clickjacking protection, a restrictive content-security policy, controlled referrer disclosure and HSTS) to reduce the attack surface of common web vulnerabilities.
• Where a SIM is on a compatible private-APN plan, its cellular traffic is routed over the carrier's private network path rather than the public internet — relevant to procurement requirements that call for connectivity with no internet-facing link.

• All traffic between a browser/mobile app and the portal is encrypted in transit using TLS.
• Passwords are never stored in plain text — they are hashed using an industry-standard, salted hashing algorithm (bcrypt) and cannot be reversed by PTT NZ staff.
• Sensitive account fields are encrypted at the application/storage layer.

Software dependencies and infrastructure are monitored for known vulnerabilities, and fixes are applied under the response commitments in section 13. In the interest of giving customers an accurate picture for their own due diligence, we disclose the following gaps rather than claim full coverage:

• We do not currently commission a scheduled, independent third-party penetration test or vulnerability assessment on a fixed (e.g. annual) cycle. This is an identified gap against frameworks that expect periodic independent testing, and we are working towards putting a programme in place ahead of any contract that requires it.
• Code and configuration changes are reviewed before release; there is no formal change-advisory board for lower-risk releases at this time.

The portal is hosted on PTT NZ-operated servers in secure data centres located in Christchurch, New Zealand, Auckland, New Zealand, and Sydney, Australia. Core account, billing and SIM-management data for this platform is processed and stored within these New Zealand/Australia facilities. Each site is supported by:

• Redundant fibre circuits for network resilience;
• Generator backup power in the event of a mains outage;
• Offsite, redundant secure backups; and
• 24/7 monitored physical access, restricted to authorised personnel only.

A small number of specific, limited-purpose functions are handled by third-party subprocessors whose own infrastructure is not confined to New Zealand or Australia. These are disclosed in full, with exactly what each one does and does not receive, in section 10.

PTT NZ uses a small number of specialist third-party providers to deliver specific portal functions. We choose providers that meet recognised security standards for their function and only share the minimum data each one needs to do its job — none of them are given a wider copy of our customer database.

• Stripe (card payment processing) — card numbers are entered directly into Stripe's own PCI DSS-compliant systems and never touch PTT NZ's servers. Stripe operates global payment infrastructure, so card-transaction data may be processed outside New Zealand/Australia as part of Stripe's standard network.
• POLi Pay (bank-to-bank online payments) — processed within New Zealand banking infrastructure for NZ bank account payments.
• Resend (transactional email delivery) — used to send account, billing and notification emails; its delivery infrastructure is operated outside New Zealand/Australia.
• Cloudflare Turnstile (bot/abuse protection on public forms) — operates a global edge network; only interaction signals needed to tell humans from bots are processed, not account content.
• Microsoft Entra ID — only used where a customer or reseller organisation has chosen to enable SSO. Identity verification happens inside that organisation's own Microsoft tenant, which the organisation itself controls and hosts.

We do not sell customer data to any third party. If a specific contract requires all processing to stay within New Zealand/Australia with no exception, tell us — we can discuss which of the above functions can be scoped out or substituted for that customer.

Administrative and security-relevant actions taken by customers, resellers and PTT NZ staff — including account changes, SSO configuration, billing adjustments and permission changes — are recorded in a comprehensive, append-only audit log, viewable by authorised staff and, for their own organisation's activity, by account and reseller administrators.

This audit trail is reviewed by staff when investigating a specific reported issue. We do not currently run automated, centralised anomaly/unusual-behaviour alerting across the audit log — this is listed as an open gap against the equivalent NCSC Minimum Cyber Security Standard in section 2.

The platform enforces strict data segregation across its reseller hierarchy: a reseller or sub-reseller can only see and manage the accounts and SIMs beneath them, and white-labelled resellers' customers are never shown PTT NZ branding, support details, or platform documents — including this page — that are specific to PTT NZ as the direct supplier.

PTT NZ maintains the following operational commitments, backed by 24/7 staffed coverage:

• Critical response — 15 minutes, 24/7. A critical security event is acknowledged and response begins within 15 minutes of being raised, at any time of day, every day.
• Critical patching — 3 hours. Once a critical vulnerability affecting the portal is identified, a fix is applied within 3 hours where a vendor-supplied patch is available. Where no fix yet exists, compensating controls (such as temporarily restricting the affected function or disabling a feature) are applied immediately while a permanent fix is developed.
• Breach notification — within 1 hour of confirmation. Affected customers are notified within 1 hour of PTT NZ confirming a reportable security breach — that is, once our incident response process has triaged and confirmed a breach affecting their data. The initial detection-to-confirmation investigation period will vary with the complexity of the incident, but a confirmed breach is not held back once confirmed.

PTT NZ is committed to aligning the portal with the Web Content Accessibility Guidelines (WCAG) 2.2 at Level AA — the standard referenced by the NZ Government Web Accessibility Standard 1.2. We have completed an internal accessibility audit and remediation pass against WCAG 2.2 AA across the public, customer, reseller and staff areas of the portal, covering areas such as form labelling, colour contrast, keyboard and screen-reader navigation, focus visibility, and reduced-motion support. Accessibility is an ongoing commitment — we continue to monitor and improve as the portal evolves, and welcome feedback at [email protected].

If you believe you have found a security vulnerability in the PTT NZ portal or mobile apps, please report it responsibly to [email protected] with as much detail as possible. We ask that you do not publicly disclose a suspected vulnerability until we have had a reasonable opportunity to investigate and address it.