PKI Requirements Checklist for SARB Vision 2030+ Readiness

Preparing for South Africa's transformed payments and identity ecosystem requires more than awareness of the headlines. The SARB NPS Vision 2030+ Consultation Paper (24 February 2026), the Payments Ecosystem Modernisation (PEM) Programme, the Authorisation Framework opening the National Payment System to non-bank participation, and POPIA together impose concrete cryptographic and identity-infrastructure requirements on every regulated participant.

This checklist compresses those requirements into an 18-point self-assessment that an executive sponsor, CISO, head of payments, or PKI lead can run through with their team in 60–90 minutes. Each item is explicitly mapped to the regulatory or operational driver behind it, so the output is directly usable in board reporting, audit response, and procurement conversations.

Axelspire built the checklist from engagement experience across SA banks, fintechs, and public-sector organisations preparing for the SARB Authorisation Framework. It reflects what we have actually seen separate clean authorisation outcomes from stuck-in-remediation outcomes — not what we think regulators ought to look at.

How to use this checklist

For each item, score one of three positions:

• Green — In place, documented, evidenced.
• Amber — Partial; in progress or implemented but not documented.
• Red — Gap; not in place.

A working baseline for Vision 2030+ readiness is roughly 70% green, 25% amber, 5% red, with no red on items that map to issuer-key custody, key ceremony, POPIA audit, or board-level governance (items 6, 9, 15, 17, and 18 below). Reds in those areas are authorisation blockers in their own right.

The checklist is the input to a remediation plan, not the output. After scoring, prioritise reds in the PEMKey/Identity and NPU/PayShap groups first (these are the operational items SARB and counterparties will see), then close governance reds, then sequence the technical and crypto-agility items into the next 6–12 months.

If you would prefer a structured working session with the Axelspire team rather than running this internally, Contact Axelspire to schedule a 60–90 minute facilitated review.

Group 1 — PEMKey and Digital Identity Trust

1. PEMKey credential issuance and verification capability

The organisation has a documented capability — production, pilot, or planned — to issue, verify, or consume PEMKey-aligned verifiable credentials using PKI-backed signatures, public-key binding, and consent mechanisms aligned with POPIA. Where the organisation is an issuer, signing keys are HSM-backed and governed under a documented key ceremony.

Mapped to: PEM digital identity foundational component; Vision 2030+ inclusive trust principle; Authorisation Framework cybersecurity expectations; POPIA consent and lawful processing.

2. National trust framework alignment

Internal PKI policies, trust anchors, and (where applicable) issuer accreditation status are mapped to the emerging SARB / PEM national trust framework for credential interoperability. The mapping is documented and updated as PEM dialogues publish further detail.

Mapped to: Vision 2030+ federated ecosystem direction; PEMKey reusability and interoperability principles.

3. Trust model documented per use case

The organisation has explicit, documented decisions for which trust model serves each PKI use case: hierarchical for internal machine identity and PayShap-class messaging, federated/issuer-holder-verifier for verifiable credentials (PEMKey-aligned products, MyMzansi-aligned identity), bridge or cross-certification at boundaries where required.

A single PKI estate trying to serve all four trust models with one topology is the most common architectural pathology Axelspire sees in SA engagements.

Mapped to: Vision 2030+ open ecosystem; PEMKey federated model; NPU interoperability.

Reference: PKI trust models for SA's federated payment and identity ecosystem.

Group 2 — NPU, PayShap, and Payment Infrastructure Integration

4. NPU / PayInc participant PKI onboarding readiness

The organisation has a documented and tested process for obtaining and managing the certificates, keys, and trust relationships required for direct NPU/PayShap participation as a bank or non-bank PSP. Where reliance on a sponsor bank's PKI is being unwound, the migration plan is in flight.

Mapped to: NPU as middle-mile infrastructure; Authorisation Framework non-bank access; PEM Programme operational readiness.

5. ISO 20022 message signing and mutual TLS readiness

Production-capable support for signed ISO 20022 payloads and mutual TLS authentication on PayShap and NPU rails. Signing keys are HSM-protected with documented rotation procedure including counterparty notification windows.

Mapped to: PayShap expansion; PEM digital payments foundational component; ISO 20022 international interoperability.

6. Issuer-key custody for externally-trusted signing roles

Any signing key whose signature will be trusted by the NPU, PayShap counterparties, SARB, or external verifiers is held in a FIPS 140-3 Level 3 (or equivalent) HSM, generated and never extracted. Cloud HSMs (AWS CloudHSM, Azure Dedicated HSM, GCP Cloud HSM) generally meet FIPS 140-2 Level 3 and are increasingly accepted, subject to residency and custody confirmation with the relevant counterparty.

This item maps directly to the security safeguards POPIA requires of responsible parties and the cybersecurity expectations under the SARB Authorisation Framework. A red here is a deal-breaker for NPU participation.

Mapped to: SARB cyber-resilience expectations; POPIA security safeguards; NPU and PayShap high-assurance requirements.

7. SC-081v3 phasing readiness for public TLS

The organisation has a plan and tooling to operate within the CA/Browser Forum SC-081v3 trajectory: 200-day maximum public TLS validity from 15 March 2026, phasing to 100 days, ultimately 47 days by 2029. (Note: SC-081v3 is a CA/Browser Forum ballot — not, as some recent advisory documents incorrectly state, a SARB initiative.)

Manual issuance is unworkable at the 47-day floor. ACME automation is the only path.

Mapped to: Authorisation Framework operational resilience; counterparty interoperability with WebPKI-trusted infrastructure.

8. High-availability revocation and status services

OCSP, CRL, or equivalent revocation infrastructure with availability and latency SLAs suitable for real-time payments and credential verification. For verifiable-credential issuance, status list and revocation registry capabilities are in place where the credential ecosystem requires them.

Mapped to: PayShap and NPU operational availability; PEMKey trust integrity.

Group 3 — Technical PKI Controls and Automation

9. Documented and rehearsed key ceremony

Generation of high-value signing keys follows a documented key ceremony with M-of-N quorum, separated custodians, video and signed attestation, and a published rotation calendar. Rotation has been rehearsed (not just theorised) within the last 24 months.

The single most common failure mode Axelspire observes: organisations treat the ceremony as a one-time event and never rehearse rotation. When the rotation event finally arrives, original participants have moved on and documentation is incomplete.

Mapped to: SARB cyber-resilience expectations; high-assurance requirements for NPU/PayShap; Authorisation Framework operational readiness.

Reference: PKI for the National Payment Utility — Problem 2.

10. ACME-based certificate lifecycle automation

Every certificate type that supports automated enrolment uses ACME (RFC 8555). Public TLS, internal service mesh, and any certificate consumer that integrates with a modern CA. Manual issuance is reserved for the small set of high-value signing keys where ceremony is appropriate.

Mapped to: SC-081v3 phasing; operational efficiency; compliance scalability.

11. ARI integration

ACME clients consult ARI (ACME Renewal Information, RFC 9773 — not "Automated Renewal/Rotation Infrastructure", an incorrect expansion that has spread through several 2026 advisory documents) for renewal-window guidance and mass-revocation signals. Current versions of Certbot, Lego, simple-acme, and step-ca support ARI; acme.sh does not.

Mapped to: Operational resilience; mass-revocation response capability.

12. Crypto-agility infrastructure

CA, HSM, ACME pipeline, and message-signing infrastructure can switch cryptographic algorithms without re-architecture. Application code does not hardcode algorithm identifiers (RSA-2048, ECDSA-P256); it reads from configuration. Hybrid certificates (classical + PQC) have been tested in non-production where the CA and HSM permit.

The relevant standards: NIST FIPS 203 (ML-KEM), FIPS 204 (ML-DSA), FIPS 205 (SLH-DSA). The relevant US federal mandates are NSM-10, OMB M-23-02, EO 14144, and the Quantum Cybersecurity Preparedness Act, with a 2035 horizon for high-value system migration. (NIST SP 800-208 is a stateful hash-based signature standard, not the PQC migration mandate — a recurring misattribution worth flagging in vendor communications.)

Mapped to: Vision 2030+ long-term resilience; PQC migration readiness; future-proofing of PEM components.

13. CA topology fit-for-purpose

CA topology (hierarchical, bridged, federated, or hybrid) is explicitly designed and documented to support current volumes plus projected non-bank and credential ecosystem growth. The decision rationale is recorded; topology is not the result of historical accretion.

Mapped to: Vision 2030+ open ecosystem; NPU interoperability; cost and operational scalability.

14. Sandbox and production validation capability

The organisation can test PKI changes, certificate rotations, and new trust relationships in realistic PayShap ISO 20022 and PEMKey scenarios before production impact. Test infrastructure exists, is maintained, and is used for every material change.

Mapped to: SC-081v3 phasing; safe non-bank onboarding; operational resilience.

Group 4 — Governance, Risk, POPIA, and Compliance

15. POPIA-aligned credential and PKI data handling

Issuance, renewal, revocation, and key-access events are logged. Logs are retained, access-controlled, and themselves processed under a documented POPIA lawful basis. Subject minimisation is enforced in certificate fields — personal information is not embedded where a stable opaque identifier suffices. Where credentials are issued, schemas support selective disclosure.

Mapped to: POPIA Sections 19–22 (security safeguards) and processing principles; PEMKey consent model.

16. Cross-border transfer documentation

Where keys, audit logs, certificate authorities, or credential infrastructure are operated outside South Africa, POPIA's cross-border transfer rules are documented and the basis for transfer (adequacy, contractual, or otherwise) is recorded.

Mapped to: POPIA Section 72; Authorisation Framework outsourcing risk.

17. PKI governance, policy, and audit framework

Board-approved PKI policy, a maintained risk register, regular internal and independent audits, and clear ownership aligned with SARB Authorisation Framework expectations and POPIA accountability principles.

A recent (within 18 months) independent review or audit has covered the PKI estate. For non-bank PSPs entering the Authorisation Framework, this is a baseline expectation; for banks already in the regulated perimeter, it should already be in place.

Mapped to: Authorisation Framework governance; POPIA accountability; overall NPS oversight.

18. Board-level visibility and Vision 2030+ roadmap

PKI risk is reported to the board or risk committee at a frequency proportionate to its materiality. For organisations whose payment, identity, or credential systems are core to revenue or licence, this is at least quarterly. Certificate-related outages and near-misses are reported as named incidents, not buried in aggregated security metrics.

A board- or Exco-sponsored PKI modernisation roadmap explicitly links PKI investment to Vision 2030+ participation milestones and competitive positioning, with allocated budget and timeline.

Mapped to: Vision 2030+ strategic alignment; Authorisation Framework governance; organisational readiness.

What a red score actually means

A red on any single item is not a crisis. A red across three or more items in the same group is.

The patterns Axelspire sees most often:

• Group 1 reds (PEMKey / identity). Usually the result of treating verifiable credentials as "just another PKI thing." The architectural correction precedes any tooling decision. Resolution typically requires architectural review, not procurement.
• Group 2 reds (NPU / payments). Often visible as missing HSM custody, untested ISO 20022 signing pipelines, or sponsor-bank dependencies that have not been unwound. Highest authorisation-blocker risk in the four groups.
• Group 3 reds (technical controls). The SC-081v3 trajectory will catch up with the organisation within 18 months if ACME is not in place. ARI and crypto-agility reds are deferred risks rather than immediate operational problems but compound quickly.
• Group 4 reds (governance). These are the items SARB and external auditors will look at first. Resolving them is rarely technical — it is documentation, board engagement, and audit cadence.

Common gaps Axelspire sees in SA engagements

Across roughly two dozen SA engagements over the last 18 months, the recurring gaps cluster as follows:

• Inventory undercount. Real certificate counts run 5–10x what the CMDB suggests. The undercount is concentrated in cloud workloads, internal service mesh, and forgotten code-signing certificates.
• Manual public TLS issuance. Still the operational default in most SA organisations. The SC-081v3 trajectory makes this an active risk, not a future one.
• Single trust-model assumption. PEMKey, MyMzansi, and similar verifiable-credential initiatives are being modelled inside existing hierarchical PKI deployments. The mismatch surfaces when interoperability with external ecosystems (EUDIW, OpenID4VC certified implementations) is required.
• Issuer keys not adequately governed. In several engagements, signing keys that would be trusted by external relying parties were held outside HSMs or in HSMs with undocumented key ceremonies. This is the single most likely Authorisation Framework blocker.
• POPIA gaps in PKI audit logging. Logging exists but the lawful basis for processing the logs is undocumented, retention is excessive, and access controls are weaker than the underlying PKI controls. This becomes visible at first regulatory review.
• Misattributions in advisory documents. Two recurring errors: SC-081v3 attributed to SARB rather than CA/Browser Forum, and ARI expanded as "Automated Renewal/Rotation Infrastructure." Both have appeared in 2026 RFPs and consultancy documents. Catch them before they go external.

Next steps

The checklist is most valuable when paired with structured remediation. Three options, in order of engagement depth:

Self-serve. Score the checklist internally, prioritise reds against the group guidance above, and build a 6–12 month remediation sequence. The Axelspire Vault contains the architectural references for each item.

Facilitated review. A 60–90 minute working session with Dan and the Axelspire team to walk through the checklist with your PKI, security, compliance, and payments leads in the room. Output: a documented self-assessment and a prioritised 90-day plan. Contact Axelspire with subject "Vision 2030+ checklist review" to schedule.

Full PKI gap analysis. A structured engagement including current-state inventory, architecture review, governance assessment, and a 6–12 month remediation roadmap aligned to your Authorisation Framework or Vision 2030+ participation timeline. Typical engagement: 4–8 weeks. Start the conversation via Contact Axelspire.

A printable PDF version of this checklist with scoring grid and per-item action templates is available on request — include "Vision 2030+ checklist PDF" in your contact message.

Cross-references

• For the strategic "why" behind these requirements: PKI trust models for SA's federated payment and identity ecosystem.
• For implementation depth on each technical item: Designing PKI for the National Payment Utility — architecture options for non-bank PSPs.

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. The checklist reflects engagement experience across SA banks, fintechs, and public-sector organisations preparing for the SARB Authorisation Framework and Vision 2030+.