# Root of Trust Dicabut: Siapa Pemilik Krisis?

> Ketika root of trust dicabut dari trust store, vacuum kepemilikan menciptakan risiko sistemik tanpa mandat jelas untuk recovery.

**URL:** https://www.ciptadusa.com/blog/root-of-trust-ownership-vacuum-20260802  
**Type:** blog  
**Author:** PT Cipta Dua Saudara  
**Category:** Keamanan Aplikasi  
**Published:** 2026-08-02  
**Cover:** https://cdn-uagents.enitip.com/uploads/blog/2026-08/daily-appsec-20260802-014622.jpg  

## Article

Sebuah root certificate dicabut. Dalam 24 jam pertama, semua orang sibuk memperbaiki koneksi yang putus. Tapi pertanyaan yang lebih mendasar muncul di hari kedua: siapa sebenarnya yang bertanggung jawab membangun ulang trust chain yang baru saja runtuh?

## Ringkasan

Ketika root of trust dicabut dari trust store, vacuum kepemilikan menciptakan risiko sistemik — tidak ada satu entitas pun yang memiliki mandat jelas untuk membangun kembali infrastruktur kepercayaan yang hilang.

## Tantangan

Root of trust adalah fondasi dari seluruh PKI (Public Key Infrastructure). Browser, operating system, dan IoT device semuanya bergantung pada sekelompok kecil root certificate yang dipercaya secara implisit. Ketika salah satu root ini dicabut — entah karena kompromi keamanan, pelanggaran compliance, atau keputusan geopolitik — dampaknya bersifat kaskade.

Yang jarang dibahas: pencabutan root certificate bukan keputusan teknis semata. Ini keputusan governance. Mozilla, Google, Apple, dan Microsoft masing-masing memiliki root program dengan kebijakan berbeda. Satu vendor bisa mencabut trust sementara vendor lain mempertahankannya — menciptakan fragmentasi kepercayaan yang membingungkan end user dan system administrator alike.

**Ownership vacuum** terjadi karena PKI dirancang sebagai sistem hierarkis tanpa single point of accountability di level root. Certificate Authority (CA) yang root-nya dicabut kehilangan kemampuan menerbitkan sertifikat terpercaya. Tapi subscriber (pemilik domain, operator server) yang bergantung pada CA tersebut tidak memiliki mekanisme otomatis untuk migrasi.

## Implikasi

Apa yang terjadi di "morning after"?

Pertama, **discovery gap** — organisasi harus mengidentifikasi semua sertifikat dalam infrastruktur mereka yang berasal dari root yang dicabut. Certificate inventory yang tidak lengkap (masalah umum bahkan di organisasi besar) membuat proses ini memakan waktu berminggu-minggu.

Kedua, **migration bottleneck** — CA alternatif harus memvalidasi ulang setiap subscriber, proses yang secara standar membutuhkan domain validation, organization validation, atau extended validation. Kapasitas issuance CA menjadi chokepoint ketika ribuan organisasi migrasi secara simultan.

Ketiga, **trust store propagation delay** — bahkan setelah keputusan pencabutan dibuat, distribusi update ke semua device membutuhkan waktu. Perangkat IoT dengan firmware update cycle 6-12 bulan mungkin tetap mempercayai root yang sudah dicabut selama setahun penuh.

Solusi yang mulai diadopsi: **certificate agility** — arsitektur yang mengasumsikan root of trust bisa berubah kapan saja. Implementasinya mencakup automated certificate lifecycle management, multi-CA strategy (tidak bergantung pada satu CA), dan pre-provisioned backup certificates yang siap diaktifkan ketika primary chain fails.

## Referensi

- [The Morning After We Pull a Root of Trust, Nobody Owns It — Dark Reading](https://www.darkreading.com/cyber-risk/morning-after-we-pull-root-of-trust-nobody-owns-it)
- [Mozilla Root Store Policy](https://wiki.mozilla.org/CA/Root_Store_Policy)
- [ACME Protocol (RFC 8555) — Automated Certificate Management](https://datatracker.ietf.org/doc/html/rfc8555)

---

*Markdown version of https://www.ciptadusa.com/blog/root-of-trust-ownership-vacuum-20260802 — generated for AI agents and LLM crawlers.*