Compliance

This page covers CNX Precision Time — both NTS and PTP tiers — and the CNX Timestamp Authority, which is anchored to the same atomic oscillators and root CA infrastructure. Authenticated timekeeping and independently verifiable timestamps are implicitly required across multiple regulatory frameworks as a prerequisite for valid audit trails, accurate transaction logs, and cryptographic certificate validity. TCRMG references are to the January 2026 edition (supersedes 2019). The table below maps CNX Precision Time capabilities to specific requirements; the TSA is covered in its own section further down.

Standards overview

Standard or framework	Applicability to CNX Precision Time
NBC TCRMG 4.10.5 (January 2026)	BFIs shall ensure that a centralised NTP server is used to synchronise time across all devices. CNX Precision Time satisfies this as an in-country, authenticated Stratum-1 NTP source. NTS (RFC 8915) exceeds the minimum by adding cryptographic authentication — each time packet is bound to a verified TLS session, making the signal tamper-evident.
NBC TCRMG 4.10.6 (January 2026)	Log information must be protected from unauthorised changes including alteration, editing, and deletion. Accurate, authenticated timestamps from CNX Precision Time are a prerequisite — logs with clock-manipulated timestamps cannot be treated as tamper-evident regardless of other controls.
NBC TCRMG 7.0 (January 2026)	Third-party supplier risk management. Anonymous public NTP pools carry no contract, no risk assessment, and no accountability. CNX Precision Time provides a contractual SLA, Cambodian jurisdiction, and a documented exit path — satisfying the outsourcing oversight requirement.
PCI DSS 10.6	Protect audit logs from destruction and modifications. NTS-authenticated timestamps are tamper-evident by construction — each time packet is cryptographically bound to the session. The time provenance chain is auditable and verifiable.
SWIFT CSP	Accurate timestamps for transaction logs in SWIFT messaging environments. CNX Precision Time provides Stratum-1 domestic source with sub-10 ms NTS accuracy — meeting the timestamp integrity standard for correspondent banking operations.
ISO 27001 A.8.17	Clock synchronisation of information processing systems. CNX Precision Time provides authenticated, domestically anchored Stratum-1 reference with 99.99% availability SLA — meeting the requirement for reliable and verifiable time synchronisation.
RFC 8915	Network Time Security (NTS) for NTP. CNX NTS implements the full RFC 8915 protocol — TLS-authenticated key exchange, per-packet cryptographic binding, client-side validation of time signal integrity.
IEEE 1588v2	Precision Time Protocol (PTP). CNX PTP delivers unicast grandmaster feed to boundary clocks at customer data centres, providing sub-microsecond hardware-level synchronisation for core switching and hypervisor estates.
NIST SP 800-57	Key Management Recommendations. The private root CA used for NTS client pinning follows SP 800-57 guidance for key lifecycle — generation, protection, rotation, and revocation.

---

NBC TCRMG (January 2026) — detailed mapping

Requirement	How CNX Precision Time addresses it
Audit trails accurate and protected (4.10)	NTS cryptographically authenticates every time packet — each is bound to a session key negotiated in a verified TLS handshake. A tampered, delayed, or substituted packet is detected and rejected. The chain of custody from atomic oscillator to server clock is documented and auditable. Timestamps produced under NTS are forensically defensible in the same way DNSSEC-signed records are cryptographically verifiable.
Third-party supplier risk (7.0)	Public NTP pools are anonymous third parties with no contract, no SLA, and no Cambodian regulatory accountability. CNX Precision Time provides: a contractual service level agreement with defined accuracy targets and availability commitments; Cambodian jurisdiction (licensed by MoPT); documented exit path (clients reconfigure to any Stratum-2 source on contract termination); and audit rights.
Business continuity — time continuity (8.0)	In-country Rubidium atomic oscillators provide autonomous holdover of less than 1 µs/day for over a year without GNSS or international link dependency. During a regional connectivity event, the time service continues from its own atomic standard. There is no degraded mode — the signal is identical whether external references are available or not.
Technology risk — network security (4.7)	The NTS client hostname is pinned locally, removing DNS from the synchronisation path. The TLS session validates only against the CNX private root CA — not the 150-organisation public CA bundle. A compromised public certificate authority cannot impersonate the CNX time service. The slow slew attack and similar NTP-based clock manipulation techniques have no mechanism to operate against NTS.
Outsourcing — data location (7.0.13)	CNX Precision Time operates entirely within Cambodia. Time signal generation, delivery infrastructure, and key management are all in-country. There is no data in the traditional sense (the service delivers a time reference, not stored data), but all infrastructure serving Cambodian clients is physically inside Cambodia under Cambodian law.

---

PCI DSS and SWIFT — additional notes

PCI DSS 10.6: The requirement is for audit log timestamps to be accurate and protected from modification. NTS does not protect the log files themselves — that is a separate control. NTS ensures the timestamps written to those logs are derived from an authenticated, tamper-evident time source. The combination of NTS-authenticated time and log integrity controls (10.5) provides the full requirement.

SWIFT CSP: SWIFT's Customer Security Programme requires accurate transaction timestamps for message integrity and replay prevention. The ISO 20022 message standard used in Bakong and correspondent banking operations depends on accurate timestamps at the sending institution. Clock manipulation of the type described in the Risk section can cause SWIFT messages to be rejected or create ordering ambiguity in high-value settlement sequences.

---

CNX Timestamp Authority (TSA)

The TSA is anchored to the same atomic oscillators and root CA infrastructure as CNX Precision Time — see CNX Timestamp Authority for the service itself. The table below maps it to the standards it operates under; the section after that describes the exact technical setup those standards require, so the chain of custody isn't just a claim — it's checkable.

Standard or framework	Applicability to CNX TSA
RFC 3161	Internet X.509 PKI Time-Stamp Protocol. CNX TSA issues standard TimeStampToken structures over the standard request/response protocol — any RFC 3161 client can request and verify tokens without CNX-specific tooling.
ETSI EN 319 421	Policy and security requirements for trust service providers issuing time-stamps. Governs signing key protection, time source accuracy, and the operational practices CNX TSA follows.
ETSI EN 319 401 §7.10	Event logging for trust service providers. Request and issuance logs are UTC-synchronised, sealed daily, and held in a form that cannot be altered or deleted except by reliable transfer to long-term media.
NIST FIPS 186-4	Digital Signature Standard. All TSA signing uses ECDSAP256SHA256 — NIST P-256 with SHA-256.
ANSI ASC X9.95	Trusted Time Stamp Standard. CNX TSA's time source — GNSS-disciplined Rubidium atomic oscillators, traceable to national metrology laboratories — meets the X9.95 requirement for a provably accurate, traceable time source. Full accuracy statement in the TSA policy.
NBC TCRMG 4.10 (January 2026)	Audit trails accurate and protected from modification. A CNX timestamp token is independent, third-party evidence of a record's state at a point in time — the chain of custody NBC examiners look for.

Chain of custody — the exact setup

Every timestamp token traces through three certificates, not one: the CNX root CA (HSM-held, non-exportable) signs a single TSA CA certificate (also HSM-held), which signs each TSA node's own signing certificate — generated and held inside that node's hardware-backed vTPM, and never exported. A token carries its full chain — signer, TSA CA, root CA — embedded in it, so it verifies against the published root CA anchor alone, without contacting CNX. That anchor is published as a DNS TXT record at _ca.cnx.net.kh — an SPKI pin of the root CA's public key — and is independently checkable; exact steps are in the Verification guide.

For subscription customers, every request and every token actually issued is logged separately — the hash submitted, the token's serial number, and its genTime — sealed daily into a tamper-evident repository on CNX's own storage inside Cambodia, per ETSI EN 319 401 §7.10. On request, sealed logs can be exported to an independent third-party custodian holding a copy separate from CNX, so records stay accessible and verifiable even if CNX is unavailable or in dispute — the same pattern used for the "Designated Third Party" custodian required for broker-dealer recordkeeping under SEC Rule 17a-4(f).

---