---
title: "Threat model"
description: "Understand licensing trust boundaries, attacker capabilities, implemented controls and limits on customer-controlled machines."
slug: "/docs/v1/security/threat-model"
section: "Security"
order: 18
audience: "all"
level: "advanced"
last_updated: "2026-10-17"
version: "v1"
related: ["/docs/v1/security/signed-responses","/docs/v1/security/threat-model"]
draft: false
---
Use licensing as one layer of authorization with explicit trust boundaries, not as a promise that a local application cannot be patched.

## What you will learn
- Identify the assets and attacker capabilities.
- Map implemented controls to realistic threats.
- Decide which operations need server-side enforcement.

## Prerequisites
- Read [signed responses](/docs/v1/security/signed-responses).
- Know whether your app runs on your server or a [customer](/docs/v1/start/glossary#customer)'s [device](/docs/v1/start/glossary#device).

## Assets and trust boundaries
Protect [developer API keys](/docs/v1/start/glossary#developer-api-key), signing private keys, [activation tokens](/docs/v1/start/glossary#activation-token), [license](/docs/v1/start/glossary#license) state, customer data and your application's valuable operations. [Public App IDs](/docs/v1/start/glossary#public-app-id) and [public verification keys](/docs/v1/start/glossary#public-verification-key) are not secrets. A public key must still be trusted for the intended origin.

Your backend is a different trust boundary from a customer's desktop, plugin host, browser or CI machine. Keep lmp_ management credentials on your backend only. Neither obfuscation nor an environment variable makes a distributed management key private.

| Attacker | Attempt | Existing control | Limit / integration responsibility |
| --- | --- | --- | --- |
| Network attacker | Edit license [features](/docs/v1/start/glossary#feature) in transit | HTTPS and Ed25519 payload signatures | Maintain TLS validation and correct trusted-key handling |
| Customer with a copied token | Use another installation's [activation](/docs/v1/start/glossary#activation) | Token binding and signed installation hash | Persist/send the [installation ID](/docs/v1/start/glossary#installation-id); a fully copied identity/cache still needs your local defense |
| Unauthenticated caller | Guess [license keys](/docs/v1/start/glossary#license-key) or flood activation | High-entropy credentials, validation and existing limiters | Rate limiting is not an identity proof or complete DDoS defense |
| Another tenant | Read or change your license | [Organization](/docs/v1/start/glossary#organization)/[product](/docs/v1/start/glossary#product)/environment-scoped queries and permissions | No formal independent tenant-isolation audit is claimed |
| Leaked [developer](/docs/v1/start/glossary#developer) key holder | Perform permitted management operations | Scoped, product/environment-bound hashed keys; revocation/rotation | A valid stolen key works within its [scope](/docs/v1/start/glossary#scope) until revoked |
| Local administrator | Patch the executable or clock | Signature checks, cache deadlines, rollback checkpoints | Local enforcement can be patched; no absolute anti-crack guarantee |
| Signing-key thief | Forge trusted snapshots | Private key retained on server, not shipped in clients | Compromise requires coordinated key rollout; no automatic historical key ring |
| Replayer | Reuse an old valid response | Signed expiry/grace, binding and local clock checks | No signed nonce/challenge; disconnected state may be stale |
| Forged [webhook](/docs/v1/start/glossary#webhook) sender | Trigger provisioning changes | Endpoint HMAC and receiver validation | Receiver must enforce timestamp/deduplication and its own business authorization |

## Design decisions
1. List each paid operation and the asset it exposes.
2. Decide whether its final authorization can run on your trusted server.
3. For local-only use, choose a bounded offline policy and explain availability limits.
4. Keep management and signing secrets out of client artifacts and logs.
5. Test negative binding, time, signature and feature cases.
6. Document recovery for lost identity, expired grace and suspected compromise.
Expected result: every important action has an owner and a trust boundary, not merely a hidden button.

## What KDPika does not prove
A license signature is not encryption, proof of buyer payment, identity verification of a person, proof of an unmodified binary, a hardware attestation or a guarantee against replay. Licensing does not process payments from your software buyers. Your store/backend remains responsible for verified purchase fulfillment and refunds.

The available privacy/export/audit mechanisms are useful controls, not a certification. This source review is not a penetration test, independent security audit or claim of immunity from attacks.

## Expected result
A design review identifies which risks are reduced and which remain on your application, backend and operational process.

## Common mistakes
- Embedding a developer key in a desktop client.
- Claiming signatures stop a local administrator from changing code.
- Using a webhook or checkout success URL as license authorization.

## Security notes
Minimize personal data in payloads and logs. Keep server backups and key access restricted. If a suspected issue involves KDPika, report it through [the disclosure policy](/security) without testing other tenants.

## Troubleshooting
| Symptom | Cause | Action |
| --- | --- | --- |
| Paid online action bypassed | Authorization enforced only in the UI | Enforce it again on your server |
| Offline revocation is delayed | Disconnected signed snapshot | Reduce grace or require online authorization |
| Security claim lacks evidence | Assumption treated as guarantee | State the limit and collect actual evidence |

## Next steps
Read [signed responses](/docs/v1/security/signed-responses) and [the threat model](/docs/v1/security/threat-model), then validate your own integration in [Sandbox](/docs/v1/start/glossary#sandbox).

## Related
- [Verification examples](/docs/v1/security/verify-ed25519)
- [Offline mode](/docs/v1/security/offline-mode)
- [Security and disclosure](/security)