Security posture

Who this page is for: the IT contact or adviser assessing the posture - the architecture, the access model, and the certification ladder with each stage’s real status.

The architecture

• Tenant-partitioned practice access. Every practice has its own tenant and its records use tenant-partitioned keys. Practice-facing API operations are authorised to the signed-in tenant. Privileged operational paths, including cross-tenant service operations, are separately controlled and audited. Production uses one encrypted DynamoDB table; this is logical tenant isolation, not a separate table or encryption key per practice. No patient data belongs in logs. Refera’s licensed-platform copies are encrypted in transit and at rest in AWS Sydney. Refera’s authorised server components process referral data to provide the service, so Refera does not describe this as end-to-end encryption or zero-knowledge storage.
• Passkey-preferred live access. A user-verified passkey is the recommended, phishing-resistant route. Staff without passkey support can combine a single-use email proof with a current code from their enrolled authenticator app. Neither factor works alone. Recovery codes enter restricted factor replacement and never open referral data. Factor changes rotate/revoke sessions, and inactivity locks a session after one hour. Refera has no passwords. Production uses the host-only __Host-refera_session cookie. The full model is on Signing in.
• Access follows the practice’s own directory (roadmap). Single sign-on with the practice’s existing Microsoft 365 or Google accounts, so access follows the people who join or leave, is on the ladder below. It cannot weaken the passkey floor.
• A standards-informed roadmap. ISO/IEC 27001 informs Refera’s security roadmap. Refera is not certified and has not claimed completion of an independent conformity assessment.

Encryption and the inbound-channel boundary

Refera encrypts the traffic and stored data it controls, but it does not make a false end-to-end-encryption claim:

• the connected portal requires HTTPS, and approved Microsoft Graph, Gmail, TLS-only IMAP and AWS service connections use encrypted TLS transport;
• the public edge accepts TLS 1.2 and TLS 1.3;
• DynamoDB data is encrypted at rest through AWS Key Management Service, and source objects use AES-256 server-side encryption in Sydney. The source bucket also blocks uploads using caller-supplied SSE-C keys, keeping its encryption method inside the reviewed AWS control; and
• authorised Refera components must decrypt and process referral content to provide the service. Refera is therefore neither zero-knowledge storage nor end-to-end encrypted.

The original inbound channel still matters. HealthLink states that messages on its healthcare messaging network are encrypted, delivery is acknowledged and email is not used for clinical-document transfer. A Microsoft 365, Gmail or IMAP connector can protect and narrowly scope the connector leg into Refera, but it cannot retroactively protect the sender-to-mailbox SMTP journey or make ordinary email equivalent to HealthLink. Refera retains the source channel as provenance and the practice chooses which channels it accepts.

Any downstream processor adds attack surface. Refera does not claim otherwise. The security case rests on minimum necessary access, a revocable connector, Australian storage for Refera’s copies, exact encryption controls, tenant-authorised practice APIs, auditable operations and a tested retention and incident-response lifecycle. Original mailbox and source-system copies remain subject to the practice’s provider and residency configuration.

Public-channel abuse controls

Public chat, browser voice, contact forms and callbacks are kept outside the patient-data lane and have layered abuse controls before any paid provider or operational notification is called. Fast edge throttles absorb bursts; atomic, salted counters enforce per-source and global spend ceilings; repeated lead submissions are idempotent; and contact/callback forms require an action- and hostname-bound challenge. The same challenge covers the assistant’s anonymous enquiry panel, and a short owner-bound delivery lease can be recovered after an interrupted Worker. A duplicate is reported as delivered only after a separate day-long content-free receipt confirms CRM capture. Raw network addresses and submitted contact text are not stored in the counter ledger.

If durable accounting is unavailable, paid model calls, browser voice minting and external lead fanout fail closed. The assistant continues to serve reviewed local product guidance, and every surface retains an email or human-contact fallback. Provider concurrency/daily limits and explicit kill switches provide an independent outer boundary. Voice is additionally capped by the provider at three concurrent calls, forty calls per day and five minutes per call, with a thirty-second silence timeout.

Refera does not expose a public SMS sending endpoint. Text suggestions in practice workflows remain staff-approved copy for the practice’s own channel; the public 1300 assistant cannot send a text.

The certification ladder

Each stage is claimed when its gates clear - and a certificate, once earned, links the certificate itself.

Stage	Status
Deployed boundary	The licensed portal and source-archive infrastructure are deployed in AWS Sydney. New workspaces open with patient-data capture off until the practice, source-lifecycle, workspace and service launch checks pass.
At launch	The committed gates: Essential Eight alignment, an independent penetration test, a privacy impact assessment, executed data processing agreements, insurance, and TGA-experienced counsel sign-off of the intended-purpose statement.
At growth	ISO 27001 certification.
Government and hospital work	IRAP, when a contract requires it.

Related

• Signing in - passkeys, the email-plus-authenticator alternative, recovery and session controls.
• Hosting and isolation - the instance model in operational terms.
• Releases and updates - security fixes ship first.