KairoLock aims to make common self-bypass methods materially harder. It does not claim to prevent every bypass, and no bypass-resistance claim is marked verified before the Windows red-team suite passes.
The intended adversary is the authorized device owner acting impulsively and attempting common local bypasses. The model does not promise resistance against a determined expert with physical access, modified hardware, alternate boot media, operating-system compromise, or destructive data loss.
Release candidates must be tested against the documented red-team matrix. The public changelog and security page will distinguish tested behavior, known limitations, and unresolved cases.
Trial and subscription state live on the authenticated server account. Privileged database and Paddle credentials remain on the server and are never embedded in the desktop client.
The marketing website does not need login, checkout, or activity data. The planned cloud layer stores only the identity, billing references, entitlement state, and release data needed to operate the product.
A dedicated security contact and responsible disclosure timeline must be configured before public release. Until then, no production security intake address is being advertised.