Access Control & Authentication Policy

Reviewed: 29 January 2026

At a glance

We enforce least privilege, role‑based access control (RBAC) and multi‑factor authentication (MFA) for privileged access.
User lifecycle is controlled via Joiner–Mover–Leaver (JML) workflows and time‑bound access.
Authentication follows NCSC good practice and UK GDPR Article 32 (security of processing).
Admin actions and access decisions are logged and monitored; access is reviewed on a defined cadence.

Purpose

To define how access to UK Postbox information systems and mail‑handling operations is authorised, authenticated, monitored and reviewed to protect confidentiality, integrity and availability of data.

Scope

Internal users: employees, contractors, temporary staff, suppliers with access to our systems or facilities.
Systems: production infrastructure, applications, networks, endpoints, mailroom equipment, support tools, data stores and backups.
Customers: customer-facing controls are set out here where relevant (e.g., MFA, session timeouts) and in the Website & Platform Terms of Use.

Principles

Least privilege: users receive the minimum access required to perform their role.
Need to know: access to mail images and KYC artefacts is restricted to vetted staff with business justification.
Separation of duties: conflicting roles are separated (e.g., deployment vs. approval; key admin vs. data access).
Zero trust mindset: authenticate and authorise every request; no implicit trust based on network location.
Security by default: MFA enforced for privileged roles; secure defaults for session and password policies.

Identity & access management (IAM)

Roles & RBAC

Access is assigned through role profiles (e.g., Support‑Agent, Mailroom‑Operator, Engineer‑Prod‑Read, Engineer‑Prod‑Write, Security‑Admin).
Role changes require manager approval and, for elevated roles, Security approval.
Service accounts are mapped to application roles with the least privileges required.

Joiner–Mover–Leaver (JML)

Joiners: identity verified; baseline training; roles provisioned via tickets; default no access until approved.
Movers: access adjusted before role change takes effect; remove no‑longer‑needed rights.
Leavers: accounts disabled same day (or within 4 hours for privileged users); remote wipe and key/token revocation performed. For involuntary terminations or where there is a risk of data exfiltration, access is revoked before or concurrent with notification to the employee.
Quarterly access recertification by managers; monthly for privileged/admin roles.

Privileged access

Admin access requires MFA and is time‑bound (e.g., just‑in‑time elevation with expiry).
Break‑glass accounts are stored in a sealed process (vault), tested quarterly and monitored; use requires a ticket and post‑use review. Break-glass credentials are rotated after each use and tested quarterly.

Authentication standards

Users (staff/contractors)

MFA: required for SSO and all administrative consoles; allowed factors include WebAuthn/security keys, authenticator app, or hardware token. SMS is fallback only.
Passwords: follow NCSC guidance—allow long passphrases, no periodic forced changes unless compromise, throttle attempts, and block breached passwords (checked against known breached password lists at registration and change). Minimum 12 characters.
Passwords are stored using Argon2id or bcrypt with unique per‑user salts; a system pepper may be used.

Customers (account holders)

MFA is available to all customers at no additional cost (enabled in account settings) and required for sensitive actions (e.g., changing recovery email, exporting bulk scans, API key management, accessing payment/KYC sections).
Session timeouts: 15–30 minutes inactivity for sensitive areas; background sessions refreshed via short‑lived tokens.
High‑risk events (new device, location anomaly) may trigger step‑up MFA.

Service‑to‑service & APIs

APIs authenticate via OAuth 2.1/OIDC or mutual TLS for internal services; tokens are short‑lived (e.g., ≤ 60 minutes) with scoped permissions.
JWTs must be signed with strong algorithms (e.g., RS256/ES256), include audience and expiry, and be validated on every request.
Rotate client secrets and certificates at least annually or on personnel/role change. Refresh tokens, where used, have a maximum lifetime of 24 hours and are rotated on use.

Session security

Use Http Only, Secure, SameSite cookies; TLS 1.2+ (1.3 preferred).
Prevent session fixation; regenerate tokens on auth changes; server‑side session invalidation on logout and password change.

Access to sensitive data

Access to digital mail images, mail metadata and KYC/AML artefacts is restricted to named roles; access requires a ticket, manager approval, and is time‑boxed.
Access to production data for support is read‑only where possible and performed via approved tooling with audit logs; screen capture/copy controls used where feasible. Where feasible, support tooling displays masked or redacted views of sensitive data (e.g., partial address, masked KYC documents) unless full access is specifically required and approved.
Exports of personal data require DPO/Security approval and are delivered via secure channels with expiry.

Logging, monitoring & reviews

Authentication events, admin actions and access to sensitive datasets are logged centrally and monitored via SIEM.
Alerting for anomalous access (impossible travel, brute force, unusual data access volumes).
Quarterly access reviews for all systems; monthly for admin roles and mail/KYC datasets.
Authentication and access logs are retained for a minimum of 12 months per Data Retention & Deletion Policy and protected from modification or deletion by non-security personnel.

Third‑party & vendor access

Vendors and sub‑processors must use named accounts, MFA, and time‑bound access with monitoring.
Access is granted only after contractual controls (DPA, confidentiality) are in place and security review completed. Sessions involving access to sensitive data by third parties may be recorded for audit purposes.
Remote access uses approved methods (e.g., SSO, VPN, or zero‑trust broker); local accounts for vendors are prohibited unless approved by Security.

Physical & mailroom access

Mail handling areas are access‑controlled; entry is limited to authorised staff/visitors with escort and sign‑in.
Anti-tailgating measures are in place at access-controlled entry points; staff are trained to challenge unescorted individuals.
CCTV coverage and visitor logs are maintained per policy.

Exceptions & emergency access

Temporary exceptions must be risk‑assessed, approved by Security (and the DPO where personal data is involved), and recorded with an expiry date.
Emergency/break‑glass access is permitted to restore operations or prevent harm and must be documented and reviewed within 2 working days.

Responsibilities

Security Lead: policy owner; defines standards and approvals; ensures monitoring and reviews occur.
Engineering/IT: implements IAM, SSO, MFA, password and token policies; manages JML.
Managers: approve access requests; perform recertification.
All staff: safeguard credentials; use MFA; report suspicious activity to security@ukpostbox.com.
Customers: keep credentials secret, enable MFA, and follow Acceptable Use and Terms of Use. We are evaluating passwordless authentication methods (e.g., passkeys/FIDO2) for future implementation.

Non‑compliance

Breaches of this Policy may lead to access suspension, disciplinary action, contract termination, and/or legal action. Security incidents are handled under the Incident Response & Breach Notification Policy.

UK Postbox Limited

13 Freeland Park, Wareham Road, Lytchett Matravers, Poole, Dorset, BH16 6FH, United Kingdom

Support: support@ukpostbox.com

Security: security@ukpostbox.com

Legal notices: legal@ukpostbox.com

Data protection: dpo@ukpostbox.com

Complaints: complaints@ukpostbox.com

Accessibility: accessibility@ukpostbox.com

Website: www.ukpostbox.com

Registered in England and Wales Company Number: 06723381

MLR registration no: XLML00000192390

ICO registration no: ZA038907