Developer documentation
Threat Model
This document describes the public integration threats QVTM SDK users must understand before production deployment.
In scope
- Provisioning token leakage
- Customer/domain context confusion
- Replay of stale challenge material
- Device state downgrade or unknown-device acceptance
- Trust verifier bypass
- Over-broad developer RBAC
- Misuse of Developer Portal docs as an authorization source
Out of scope for SDK consumers
- Implementation details of post-quantum cryptographic primitives
- Internal Control Plane storage architecture
- Infrastructure hosting controls outside the published API boundary
Required mitigations
| Threat | Required mitigation |
|---|---|
| Provisioning token exposed to browser/mobile | Rotate token, audit use, move token to backend-only storage |
| Wrong customer/domain used | Validate customer/domain IDs before issuing invites or challenges |
| Stale challenge accepted | Enforce expiration and status checks before creating local sessions |
| Verifier bypass | Make verifier success mandatory for application access |
| Developer has broad access | Scope SaaS Developer RBAC to required customers/domains only |
| Docs mistaken for authority | Treat Developer Portal as documentation only, never as authorization |
Production stance
QVTM integrations should fail closed. If a system cannot determine whether the device, challenge, customer/domain, or verifier evidence is valid, the application must deny access and require a fresh approval flow.