Auditing Tools for Human Rights Defenders: Our Methodology

November 5, 2025 · audits, methodology, human-rights

A common question when auditing technology under pressure: what is different about auditing a tool used by a human-rights defender versus a tool used inside a bank? At the technical level, surprisingly little. The authentication protocols, parsers, and cryptographic choices are the same machinery anyone else uses.

What changes is the threat model, and the stakes.

Start with the threat model

For the tools we audit through the Open Technology Fund Security Lab, the adversary is typically a powerful, persistent state actor. The user is often someone who cannot afford to be detected, let alone compromised. That focus reshapes the audit in concrete ways:

  • Device seizure is the baseline. We assume the device may be physically confiscated. Every secret an app stores, or fails to store, must be justified against that possibility.
  • Network tampering is assumed. Implanted certificates, poisoned DNS, and captive portals are the default network environment, not the exceptional one.
  • Privacy under coercion. The app should not offer anything that could implicate someone for merely possessing the tool.

The methodological core

The audit method comes down to a few simple-seeming questions, asked again at every layer of the stack:

  1. What data touches the device, and what is it allowed to do?
  2. Can an attacker influence execution paths without credentials?
  3. What happens on failure, and is the failure mode the safe one?
  4. Are the design’s claims independently verified? Does encryption actually encrypt? Is the “secure store” reachable through a debug interface?

We pair manual code review with dynamic analysis, and classify every finding against a clear rubric so downstream teams can act fast. Confidential and partial-class findings get reproduction steps and remediation suggestions. Findings you can act on, not abstract warnings.

Findings are the product, not a score

The useful output of an audit is not a grade. It is a set of findings that let maintainers change their software with confidence. In practice:

  • Reproducibility first. Each issue includes the exact conditions that trigger it and the exact conditions that verify the fix.
  • Prioritized triage. We rank by exploitability, not just by CVSS homework, because real attackers chain weaknesses.
  • Fix-oriented writing. Findings point to the design decision that allowed the problem and, where reasonable, propose a concrete remediation.

Why we publish some of it

Several of our audit reports are public, including Tella and NetAidKit, because transparency raises the baseline for the whole ecosystem, not just one vendor. Public findings can be studied, verified, and cross-referenced by any researcher. Getting audited is already a workout. Publishing the report makes the exercise count beyond your own project.

If your project serves people facing real adversaries and you want security work that is rigorous and verifiable, we take on engagements. The starting point is our services page.