PKI Trust Models for South Africa's Federated Payment and Identity Ecosystem (SARB Vision 2030+)
TL;DR
SARB Vision 2030+ does not require a single PKI trust model. It requires four overlapping ones — and the dominant architectural mistake Axelspire sees in South African engagements is treating Vision 2030+ as a single PKI problem.
- National Payment Utility (NPU): hierarchical PKI internally, bridge or cross-certification at the perimeter. Inter-institutional trust is the hard part.
- PayShap: hierarchical PKI for ISO 20022 message signing and mutual TLS to the clearing layer. Operational pressure is automation, not trust topology.
- PEMKey: federated issuer-holder-verifier. Verifiable credentials, not X.509 certificate chains. Hierarchical PKI underneath, but the trust validation flow is different.
- MyMzansi digital identity: wallet-based digital public infrastructure with authoritative issuers. Hybrid by design.
If you only have time to read one section: the comparison table below.
Why this page exists
Every PKI engagement Axelspire has run with a South African organisation in 2026 has had to start by separating four things that the public discourse keeps merging:
- The trust model needed for interbank settlement and clearing infrastructure (NPU, SAMOS successor systems).
- The trust model needed for fast-payment messaging integrity (PayShap, ISO 20022).
- The trust model needed for portable digital credentials (PEMKey, verifiable claims).
- The trust model needed for citizen identity verification (MyMzansi, Home Affairs digital ID).
These are not the same problem. They have different threat models, different governance assumptions, and different implementation primitives. A single hierarchical PKI cannot serve all four well, and a single federated wallet ecosystem cannot serve all four well either.
This page assumes you already understand the three foundational PKI trust models. If you don't, start with hierarchical, bridge, and web-of-trust models compared and come back. From here on, the focus is the South African ecosystem specifically.
Classic root CA → issuing CA → end-entity. Closed regulated participant set, single trusted root, online OCSP/CRL revocation. Mature operational tooling and audit patterns.
SA mapping: NPU participant access; PayShap message signing and mTLS
Why this model
- •Closed regulated audience matches the historic strength of hierarchical PKI.
- •Online verification supports OCSP/CRL revocation patterns.
- •A single trusted root maps directly to one issuing CA chain.
- •Consumers already expect X.509 — no second verifier stack required.
Fit across all four trust models
The four SA initiatives, mapped
1. National Payment Utility — hierarchical with federation at the edge
The NPU is the SARB's flagship infrastructure consolidation. PayInc (formerly BankservAfrica) holds the operator role; SARB took a 50% stake in November 2025. The PEM consultation paper positions the NPU as middle-mile infrastructure that must accommodate banks, fintechs, and non-bank PSPs simultaneously.
Trust topology that fits:
- Internally: hierarchical PKI rooted in an NPU root CA with policy CAs for each participant class. This is standard interbank infrastructure design and matches how SAMOS and the existing RTC environment have always worked.
- At the perimeter: bridge CA or cross-certification with each participant's existing PKI. Banks already run AD CS hierarchies; non-bank PSPs run a mix of public CA usage and internal microservice PKIs. Forcing every participant to enrol against the NPU's internal hierarchy creates operational friction that defeats the inclusion goal.
Where Axelspire sees this go wrong: treating the NPU PKI as a closed hierarchy and then using out-of-band shared secrets, mutual TLS with self-signed certificates, or token-based authentication to onboard non-bank participants. This works for the first ten participants. It does not work for the hundred-and-tenth.
The structural fix is name constraints, certificate transparency-style logging at the bridge, and policy mappings between participant CAs. Conventional in EU central bank infrastructure (TIPS, T2-RT1). Not yet conventional in SA.
2. PayShap — hierarchical PKI, automation as the bottleneck
PayShap's trust model is the simplest of the four. ISO 20022 messages need integrity protection and non-repudiation. Mutual TLS terminates between participants and the clearing layer. Each participant needs a small, well-governed set of signing and TLS certificates from a CA the counterparties trust.
The hard problem is not topology. It is operational tempo.
Three operational pressures:
- Certificate validity is collapsing. From 15 March 2026 the CA/Browser Forum SC-081v3 ballot moved the maximum public TLS validity to 200 days. The phasing continues to 100 days and ultimately 47 days by 2029. Any participant still issuing year-long certificates and renewing manually is on a trajectory to outage.
- Message-signing keys have their own lifecycle. ISO 20022 message authentication code or signature keys typically rotate slower than TLS, but rotation must still be coordinated with all counterparties. In a hub-and-spoke model where the NPU operator sees every participant's signing certificate, key rotation becomes a scheduled industry event rather than an internal ops task.
- Crypto-agility is now a regulator concern. SARB has not yet published explicit PQC guidance for PayShap, but the global direction is unambiguous: NIST FIPS 203 (ML-KEM), FIPS 204 (ML-DSA), and FIPS 205 (SLH-DSA) are the standards counterparties will eventually require. US federal mandates under NSM-10, OMB M-23-02, and EO 14144 already set 2035 as the migration horizon for high-value systems. PayShap participants who lock themselves into a single signing algorithm without an upgrade path will pay for it later.
The right architecture for PayShap is a hierarchical CA with full ACME (RFC 8555) automation, ARI (RFC 9773) for renewal coordination, and an issuance policy that supports multiple algorithms in parallel. Trust model: hierarchical. Engineering challenge: lifecycle automation and crypto-agility.
For the architectural detail, see Designing PKI for the National Payment Utility: architecture options for non-bank PSPs.
3. PEMKey — federated, issuer-holder-verifier
PEMKey is the initiative most often misclassified as "just another PKI thing." It is not.
The 9 April 2026 SARB PEM Industry Dialogue described PEMKey as a secure, reusable, trusted digital proof of identity. Panellists included Maeson Maherry (Ascertia, ex-LawTrust) and a cross-section of SA fintech PKI leaders. The technical pattern that fits this description and the broader Vision 2030+ architecture is verifiable credentials: an authoritative issuer signs a credential, the holder stores it in a wallet, a verifier checks the signature without contacting the issuer.
Trust topology that fits:
- Issuance: hierarchical PKI for issuer signing keys. The issuer CA must be trusted by every verifier ecosystem.
- Holding: citizen or customer wallet, on-device, no central directory of credentials.
- Verification: cryptographic verification of issuer signature plus optional revocation check (status list, OCSP, or revocation registry).
This is the same topology used by the EU Digital Identity Wallet (EUDIW), California's mDL programme, and the OpenID4VC ecosystem. The OpenID Foundation began self-certification for OpenID4VP and OpenID4VCI in February 2026 — the international interoperability rails are already in place.
The architectural mistake to avoid: modelling PEMKey as a centralised credential database with API access. That collapses the privacy property (verifiers should not learn which other relying parties a holder has used) and recreates the very problem federated identity is meant to solve. The verifiable-credential pattern exists because hierarchical PKI cannot natively support the "many issuers, many verifiers, holder controls disclosure" topology.
Hierarchical PKI is still load-bearing here. The issuer signing keys must be anchored in a CA whose root certificate is widely trusted. That is where conventional PKI engineering applies. But the trust validation flow that a verifier executes is not certificate chain validation — it is credential signature verification plus issuer trust list lookup plus optional status checking.
If your team is building or integrating with PEMKey and you find yourself trying to map it to your existing AD CS hierarchy, that is the signal to step back and read the spec rather than reuse the topology.
4. MyMzansi — hybrid, with hierarchical PKI underneath
The MyMzansi Digital Transformation Roadmap, led by the Digital Services Unit, ties together SARB digital financial ID work, Home Affairs identity overhaul, and a national data exchange layer. Phase one (2025–2027) targets a single digital identity, a payments system, a verifiable-credentials wallet, and citizen-facing platforms.
The trust architecture is necessarily hybrid:
- Hierarchical PKI anchors issuer keys for Home Affairs (ID, passport, driver's licence credentials), SARB (financial credentials), SARS, and sectoral issuers.
- Verifiable credentials carry the actual citizen-facing claims, presented from a wallet.
- Bridge or cross-certification is needed where issuer trust must extend across organisational boundaries — e.g., Home Affairs credentials being trusted by a private bank's KYC flow without each bank explicitly enrolling against Home Affairs' CA.
The architectural risk Axelspire watches for: organisations treating the credential layer as the PKI and ignoring the issuer-key infrastructure. Issuer signing keys for a national ID system are some of the highest-value cryptographic assets the country will operate. Their key ceremony, HSM custody, and rotation governance need to be designed at central-bank standard, not enterprise standard.
Comparison table: SA initiatives and their trust models
| Initiative | Primary trust model | Underlying PKI? | Key validation flow | Most common architectural mistake |
|---|---|---|---|---|
| NPU | Hierarchical + bridge/cross-cert at perimeter | Yes — internal hierarchy plus participant CAs | X.509 chain validation, possibly through bridge | Closed hierarchy that breaks when non-bank participants scale |
| PayShap | Hierarchical | Yes — direct | X.509 chain validation, mutual TLS | Manual cert lifecycle; missing crypto-agility |
| PEMKey | Federated (issuer-holder-verifier) | Yes — issuer signing keys only | Credential signature + status check | Centralised credential database; mapping to hierarchical PKI |
| MyMzansi | Hybrid (hierarchical + federated) | Yes — issuer keys for each authoritative party | Mixed: chain validation for issuers, credential verification for claims | Treating the wallet layer as the entire PKI |
What this means in practice
The SA banks and large PSPs Axelspire works with end up needing all four trust models running simultaneously, often in the same operational team. The realistic shape of a 2026 SA PKI estate looks like:
- An internal hierarchical CA (typically AD CS, EJBCA, or a managed PKI service) for machine identity and internal services.
- Public CA usage for external TLS, code signing, and any externally-trusted certificates.
- A signing key set for ISO 20022 / PayShap / NPU participation, anchored in HSMs with a rigorous key ceremony.
- A separate issuer signing infrastructure for verifiable credentials (PEMKey, MyMzansi-aligned products), again anchored in HSMs but with its own governance.
- Where the organisation issues credentials trusted by other ecosystems, a bridge or cross-certification arrangement.
This is four-to-five distinct PKI control planes. Most SA organisations Axelspire engages with started with one (AD CS) and bolted things on. The result is fragmentation: different teams, different audit trails, different rotation cadences, different vendors for HSMs and CAs.
The architectural correction is not "consolidate everything onto one CA." It is "consolidate the control plane across multiple backends so that policy, audit, and lifecycle management are unified even when the underlying CAs are not." That is the design 3AM was built for: a serverless multi-PKI control plane that integrates with AWS KMS, AD CS, EJBCA, public CAs, and verifiable-credential issuers behind a single policy and logging surface. Where the structural weakness in the SA ecosystem is fragmentation across four trust models, the structural fix is a control plane that does not require ripping out any of them.
Common questions Axelspire gets in SA engagements
"Can we use AD CS for all of this?"
For internal machine identity and many enterprise scenarios, yes. For PayShap message signing keys, AD CS works mechanically but the key custody and audit posture are usually below central-bank expectation. For PEMKey-style verifiable credentials, AD CS is the wrong primitive — it issues X.509 certificates, not VC-format credentials. For NPU bridge participation, AD CS can be cross-certified but the policy and name-constraint configuration is non-trivial.
"Should we use a public CA for everything?"
Public CAs are appropriate for externally-trusted TLS and code signing. They are inappropriate for internal machine identity at scale (cost, lifecycle constraints, and the SC-081v3 trajectory toward 47-day validity makes manual operations untenable). They are also inappropriate as issuer keys for verifiable credentials, where the issuer trust list is governed by the credential ecosystem, not the WebPKI root programme.
"Does Vision 2030+ mandate any specific PKI standard?"
As of the February 2026 consultation paper, no. The paper sets ecosystem principles — interoperability, inclusion, safety — and the operational details are being worked through PEM industry dialogues. Architects building toward Vision 2030+ should align with international interoperability standards (ISO 20022 for messaging, OpenID4VC and W3C VC for credentials, NIST PQC for crypto-agility) because those are the standards SARB is implicitly tracking.
"What about POPIA?"
POPIA constrains how personal information is processed across all four initiatives. For PKI specifically, the relevant areas are: subject identifier minimisation in certificate subjects, audit logging that captures issuance events without leaking unnecessary personal data, key custody arrangements that meet the security safeguarding requirements, and data minimisation in credential schemas (verifiable credentials are well-suited here because they support selective disclosure). The Vision 2030+ readiness checklist maps each PKI requirement to the corresponding POPIA principle.
"Where do I start?"
If you are responding to Vision 2030+ as a regulated participant, start with a current-state inventory: what CAs you operate, what certificates you consume, where your signing keys live, and what your current lifecycle automation coverage is. The downstream architectural choices follow from that. The PKI Requirements Checklist for SARB Vision 2030+ Readiness is built to support that conversation.
Where to go next
- For the architectural detail on NPU participation specifically: Designing PKI for the National Payment Utility: architecture options for non-bank PSPs.
- For an executive readiness self-assessment: PKI Requirements Checklist for SARB Vision 2030+ Readiness.
- For the foundational trust-model concepts: Hierarchical, bridge, and web-of-trust models compared.
If your organisation is responding to SARB Vision 2030+, scoping PKI for PayShap or NPU participation, or designing trust architecture for PEMKey or MyMzansi-aligned products, Dan Cvrcek and the Axelspire team are available for advisory engagements. Contact Axelspire for an immediate technical conversation.
Related Resources
Authored by Dan C. (Axelspire). Axelspire is a vendor-neutral PKI and certificate lifecycle management consultancy. Dan's PKI background is in financial services and post-doctoral cryptography research at the University of Cambridge.