Side-by-side breakdown
| Dimension | Black-box | White-box |
|---|---|---|
| Info given to tester | Just the device and its external interfaces. | Source code, threat model, design docs, SBOM, credentials. |
| Simulates | External attacker with zero insider knowledge. | Informed adversary who has compromised internal documents or staff. |
| Coverage | Strong on external-facing attack surface; limited on internal logic. | More internal visibility; coverage still depends on scope, access, methods, and evidence. |
| Effort | Schedule depends on device scope, access, reporting, fixes, and retesting. | Schedule and fee depend on agreed scope and access; no universal cost-per-finding advantage. |
| Premarket evidence relevance | Record the external-only access model and resulting coverage limits. | Provide internal evidence where appropriate and document coverage and limitations. |
| When to choose | Sanity-check a release candidate; vendor due diligence. | Premarket submission; deficiency-letter response; PMA support. |
When to use which
Default to white-box or gray-box testing for any premarket submission. Provide the testers with the threat model, SBOM, design docs, and a non-production credential set so they can verify each documented control.
Use black-box testing later in the lifecycle as a periodic external-attacker check (e.g. annually or after major releases), not as the primary premarket evidence.