Security and compliance: encrypted, signed, accountable
izgate's security architecture isn't a single feature; it runs through every layer of the design, from how secrets are stored, to the license verification protocol, to how it connects to your firewall, to sub-user permissions. This page summarizes, at a technical level, what's under the panel's hood and how it behaves across license states.
This page is for information only and is not a substitute for legal advice. We recommend confirming with your legal counsel exactly how these obligations apply to your organization.
5651 compliance
5651 compliance in izgate is backed by three independent layers of proof: every archive segment is signed with Ed25519, chained to the one before it with a per-tenant SHA-256 chain, and once a day a Merkle root carrying the digest of that day's not-yet-timestamped segments receives a qualified timestamp from the Public Certification Authority (Kamu SM) via İzHost's central service. User ↔ IP/log matching happens through an alias code on guest Wi-Fi, and through the RADIUS session on office Wi-Fi. Raw identity information (phone number, Turkish ID number) is never written to the firewall or to a log line. For a detailed obligations guide, see 5651-compliant logging; for the exact wording of the articles, see the Legislation page.
License protocol v2
The license verification request is sealed to the İzHost license center's X25519 public key; no field, including the license key, ever travels over the network in the clear. The center's response is a document signed with Ed25519, and the verification gate only ever looks at this signed document — manually editing the license field in the database opens nothing, because the gate trusts the document, not the record. If the İzHost center can't be reached, the panel offers a countdown-based 3-day tolerance, during which the system runs at full capacity. There's also clock-rollback detection: an attempt to extend a license document's validity by rolling the server clock back (a cloning/copying attempt) is detected and blocked.
License states
The panel behaves differently depending on the license's current state. The table below summarizes what each state means.
| State | Meaning |
|---|---|
valid | License is valid, all features are on. |
dev | Development license (a -tags devlicense build); not present in the customer build. |
missing | No key has been entered. |
invalid | The center rejected the key (expired, revoked, over quota, etc.). |
unreachable | The center can't be reached; the panel keeps working through a 3-day countdown tolerance, then locks once it runs out. |
suspended (cloud only) | Tenant is suspended: the portal and panel display shut off, collection continues. |
disabled (cloud only) | Tenant is disabled: login and existing sessions are refused, data is never deleted. |
In an unlicensed or invalid state: log collection and archiving continue; only search, statistics and device metrics are hidden, and the guest portal returns a "license required" error. No record is ever lost.
Encrypted secret storage
The RADIUS shared secret, the firewall API token, the SMS provider secret, and the KPS (NVİ) password are all kept encrypted in the database and are either masked or never returned in API responses. Panel credentials (RADIUS secret, API password, KPS password) are never written to any log line.
TOFU certificate pinning
When connecting to a firewall's management API (FortiGate, MikroTik), izgate pins the certificate fingerprint using a "trust on first use" (TOFU) principle. If the device's certificate later changes unexpectedly, the connection is rejected; this blocks a man-in-the-middle device from quietly inserting itself. The "API Test" screen also verifies the fingerprint match.
Backoff (rate limiting)
After an unauthorized access attempt against a firewall (a 401/403 response), izgate automatically backs off for 15 minutes on that same address+key combination and doesn't retry. This is to avoid accidentally triggering the firewall's own login-failure lockout mechanism (e.g. an IP lock after "Admin login failed") — a misconfigured API key doesn't end up locking the firewall out on itself.
Alias codes and KVKK
Every person verified on guest Wi-Fi is assigned a fixed alias code (mg-xxxxxx); the firewall, RADIUS and log lines get this code, never the real identity. The alias-to-identity mapping is kept (encrypted) only inside izgate and is resolved only on the authorized search screen. This design delivers the user ↔ log matching that 5651 requires while keeping raw identity information (phone number, Turkish ID number) out of traffic records — consistent with KVKK's data-minimization principle.
Handoff to private addresses only
Once a guest is verified, the handoff to the firewall can only be directed to a private network address (RFC1918/CGNAT) or the network's predefined address list. Identity information is never sent to an external (public internet) address; this architecturally blocks identity from being leaked out by abusing handoff parameters.
Sub-user permissions
In izgate Cloud, sub-user permissions use the same model as the izhost.com panel: the account owner grants whichever permission they want to whichever person, from a shared permission catalog (8 keys) at the İzHost center; every key granted automatically narrows that person's panel menu and page access.
| Key | Access it unlocks |
|---|---|
full_access | The entire panel; License and account management also only open with this permission. |
view_only | Read-only general access to the panel. |
logs | Live Logs (search, filters, facets, timeline). |
archive | Archive page (verification, download, export, restore to live). |
devices | Devices page and Rules page. |
manage | Wi-Fi Management (Guest/Office Wi-Fi, Portal Designs, settings). |
guest_desk | Guest Desk — Pending Approvals, Visitor Codes and Sessions only. |
settings | General settings and Disk Management. |
In an on-premises install, login is local (an izhost account is optional) and there's only a single (default) tenant; the sub-user catalog doesn't apply in this mode.
About security and compliance
If my license expires, are my logs lost?
No. Log collection and signed archiving continue uninterrupted even in an unlicensed or invalid state; only search, statistics, device metrics and guest portal screens go dark. No record is ever lost.
Where are my firewall API credentials stored?
The RADIUS shared secret, the firewall API token, the SMS provider secret and the KPS password are stored encrypted; they're masked or never returned in API responses, and they're never written to any log line.
If I manually change the license key in the database, does the license unlock?
No. The verification gate only looks at the Ed25519-signed document coming from the İzHost center; manually editing the display fields in the database opens nothing.
What happens if I keep trying to connect to my firewall with the wrong API key?
After a 401/403 response, izgate automatically backs off on that same address+key for 15 minutes; this prevents the firewall's own login-lockout mechanism from being triggered by accident and cutting off your access to the device entirely.
Where do I manage sub-user permissions?
In izgate Cloud, sub-user permissions are managed through your izhost.com account, using a shared catalog of 8 keys; each key automatically narrows the panel menu. In an on-premises install, there's only a single (default) tenant, so this model doesn't apply.
Does a guest's real identity show up in firewall logs?
No. Raw identity (phone number, Turkish ID number) is never written to the firewall or log lines; every guest is assigned a fixed alias code (mg-xxxxxx), and the code-to-person mapping is kept encrypted only inside izgate.
Making your network Law No. 5651 compliant is a one-day job.
Configure izgate Cloud based on your number of firewall devices and storage needs; no setup, get started in minutes. Call us with any questions.