Non-repudiation 的核心概念是產生某個值的一方無法否認自己產生過它，成立條件是只有那一方具備產生的能力。這個性質決定了驗證機制的選型：共享密鑰的 Message Authentication 兩端都能產生對方看來合法的值，驗證值本身因此不足以支持事後追究；非對稱簽章由私鑰產生、公鑰驗證，驗證方不具備產生能力，追究的根據就在憑證本身。第三條路是引入獨立見證（時間戳權威、雙方都無法單方改寫的記錄），此時舉證能力來自見證機制而非原語。

概念位置

Non-repudiation 位在完整性與來源驗證之上的一層。完整性回答「內容有沒有被改」，來源驗證回答「這是不是持有密鑰的一方發的」，不可否認性回答的是「能不能對第三方證明是他發的」。前兩者在雙方互信的點對點整合裡就夠用，第三者要在爭議發生時才顯出必要。

它與 Audit Log 的分工是：稽核記錄提供「系統認為誰做了什麼」的紀錄，不可否認性提供「當事人無法主張這筆紀錄是別人偽造的」的根據。稽核記錄由系統自己寫入時，系統管理者本身在爭議中不具備舉證能力，這是稽核記錄需要外部簽章的原因。

可觀察訊號與例子

需要正視這個要求的訊號是流程裡出現「事後可能有人否認」的環節：金流指令、合約承諾、審批動作、以及對外發佈的憑證。這些場景的共同點是爭議發生時需要向第三方舉證，而非只在雙方之間確認。

常見的失效是用共享密鑰處理需要追究責任的場景。密鑰兩端都有，發生爭議時任一方都可以主張是對方偽造的，驗證值無法區分。這個缺口在系統正常運作時完全不顯現。

另一個訊號是同一把私鑰被多個服務共用。能產生簽章的主體一旦超過一個，簽章就只能證明「來自這群服務之一」，追究到具體哪一個的能力就消失了。

設計責任

設計時要先確認需求層級：雙方互信的點對點整合用共享密鑰即可，需要對第三方舉證或對不特定多方發佈可驗證憑證時才用非對稱簽章。這個判斷影響金鑰管理成本，過度提升層級會帶來不必要的治理負擔。

私鑰即信任根，它的保存要與一般應用程式 secret 分層，納入 Key Management 與 HSM 的保護範圍。私鑰失守的後果是所有下游驗證同時失去意義，這與一般憑證洩漏受自身權限限制是不同層級的失效。

簽章要涵蓋能識別責任主體與時點的欄位。只簽內容而不簽發起者與時間時，簽章證明了內容未被竄改，仍然無法回答是誰在什麼時候做的。