This guide is for software vendors and integration teams whose products depend on NASH certificates — anything touching My Health Record, electronic prescribing, the Healthcare Identifiers Service, or secure messaging. NASH is a single point of failure for all of it: when the certificate is wrong, expired, or installed badly, every national digital health function in the product stops at once.
It explains what NASH actually is, who issues what to whom, and the recurring setup failures that generate most of the support load.
What NASH certificates actually do
NASH — the National Authentication Service for Health — is the PKI that authenticates healthcare organisations to Australia's national digital health systems. Services Australia issues the certificates; the Australian Digital Health Agency's services rely on them. One NASH organisation certificate typically secures all of a site's national integrations: mutual TLS and message signing to the My Health Record B2B Gateway, Healthcare Identifiers Service calls, electronic prescription exchange traffic, and encryption for secure message delivery.
Two distinctions trip people up constantly. First, NASH is not PRODA: PRODA authenticates people and software devices to Services Australia's own channels (HPOS, Medicare Web Services), while NASH authenticates organisations to national digital health infrastructure. A practice generally needs both, for different things. Second, NASH is not the old Medicare PKI: legacy Medicare site certificates and NASH SHA-1 certificates have both reached end of support — current integrations use NASH SHA-2.
Organisation vs individual certificates
The NASH organisation certificate is the workhorse. It is issued against the organisation's HPI-O (the seed or network organisation registered in the Healthcare Identifiers Service) and identifies the organisation, not any person. Every B2B transaction your software makes to national systems is signed with it, and gateways check that the certificate matches the HPI-O asserted in the message.
Individual PKI certificates are, for practical purposes, history: Services Australia has replaced individual certificates with PRODA for authenticating people. If your architecture or an old integration document assumes a clinician holds their own NASH certificate, treat that as a legacy assumption and check Services Australia's current NASH guidance. Individual providers are identified inside messages by their HPI-I; the cryptography is organisational.
How issuance and renewal work
For production certificates, the flow runs through HPOS, and only a specific person can drive it: the organisation's OMO (Organisation Maintenance Officer). The OMO logs into HPOS via PRODA, requests a NASH SHA-2 certificate for the organisation's HPI-O, and nominates the software product in use — the product list matters, because it flags SHA-2 compatibility. A PIC (Personal Identification Code) is sent to the OMO's registered mobile; it doubles as the password protecting the downloaded keystore.
Certificates are valid for two years. The OMO receives a renewal notice through HPOS mail ahead of expiry — but that notice goes to the practice, not to you, which is exactly why vendors get blindsided. Renewal issues a new keypair, not an extension: the new keystore must be installed everywhere the old one was.
Certificates for development and testing
Developers don't get SVT credentials from HPOS. Test NASH certificates for the vendor test environments come through the Agency's developer onboarding — see the Digital Health Developer Portal — bound to test HPI-Os. Keep the two worlds strictly separated in configuration; a test certificate presented to production (or vice versa) is one of the most common first-connection failures.
Operational reality for software vendors
If you ship software that depends on NASH, certificate lifecycle is a product problem, not a customer problem. The practices running your software mostly don't know what an OMO is until something expires. The vendors with the fewest outages do three things: surface certificate expiry inside the product (loudly, weeks out), document the HPOS renewal walk-through in plain language for practice managers, and make installing a replacement keystore a guided operation rather than a file-copying exercise.
Design for rotation from day one. The keystore path, password handling, and which components read the certificate should all tolerate a swap without downtime — including any background services that cache the old credential in memory until restarted.
Treat the keystore and its PIC as production secrets, because that's what they are: together they let anyone transact as the healthcare organisation. They belong in proper secret storage with access control and an audit trail of which systems hold copies — not attached to the support ticket, not in a shared drive named 'certificates', and not emailed between the practice and your onboarding team, which is exactly how they usually travel today.
Common NASH setup failures
In rough order of how often they burn people:
- Expired certificate, no warning. The renewal notice went to an HPOS mailbox nobody checks, and the first symptom is every upload and lookup failing at once on a Monday morning. Monitor expiry from inside your software; two years is exactly long enough for everyone to forget the process.
- Renewed but not replaced. The OMO dutifully renews in HPOS and assumes the job is done. The new keystore never gets installed, and the site fails when the old certificate lapses. Renewal is issuance plus deployment.
- PIC problems. The keystore password is the PIC sent by SMS to the OMO's mobile. Lost PIC, changed phone number, or a departed OMO all mean the downloaded keystore can't be opened, and the fix is a new request — with correct OMO details in HPOS first.
- Wrong certificate presented. Test certificate in production, production certificate in SVT, or a legacy Medicare PKI / NASH SHA-1 certificate that stopped being supported. The resulting TLS and signature errors are generic; check which credential is actually loaded before debugging anything else.
- Certificate/HPI-O mismatch. The certificate belongs to one HPI-O and the software asserts another — common in multi-site groups, after practice mergers, and in hosted deployments where a client organisation's traffic goes out under the wrong tenant's credential. Gateways reject the transaction even though the certificate itself is valid.
- Incomplete chain or blocked revocation checks. The keystore is installed but intermediate CA certificates aren't trusted, or a firewall silently blocks the endpoints used for revocation checking. Both produce intermittent, environment-specific failures that pass in one network and die in another.
- One certificate, many systems, partial rotation. The same NASH certificate often serves the CIS, a messaging agent, and integration middleware. Rotating it in one place and not the others leaves a site half-working — the practice sees prescriptions flowing while document uploads fail, and the correlation is not obvious to anyone on the phone.
- Clock drift. Signed requests carry timestamps and the gateways check them. A server that has drifted a few minutes produces authentication failures that look exactly like certificate problems and disappear after a reboot 'fixes' NTP.
Where to check current requirements
Issuance mechanics, supported certificate types, and transition deadlines change on Services Australia's schedule, not this guide's. The authoritative sources are Services Australia's NASH pages for production issuance and management, and the Digital Health Developer Portal for developer and test-environment credentials. If you're building the integrations that sit on top of NASH, the My Health Record integration guide covers where the certificate actually gets used.
Wrestling with NASH across a fleet of customer sites, or designing certificate handling into a new product? CareForge has done the lifecycle work — issuance flows, rotation tooling, and the support playbooks that keep sites online. Book an intro call.
Last reviewed: July 2026