Foundation / Security Information
Identity, sessions, authorization, bounded requests, replay defense, private evidence, audit, monitoring, and independent feature gates must agree. No single visible control proves the whole system safe.
This is not a certification, penetration-test report, incident report, vulnerability-disclosure program, bug bounty, testing permission, or production-security guarantee.
Independent layers / bounded authority / recorded outcomes
Current evidence
Repository tests demonstrate fail-closed foundations. Provider, environment, operations, recovery, and secure-tag controls still need their own production evidence.
Nine layers
Trusted providers, server records, Rules, state machines, bounded operations, and recorded staff authority enforce protected action.
Who is attempting to act.
Whether the signed-in session remains active and recognized.
Whether the actor may access the record or action.
Whether lifecycle, restrictions, entitlement, and stage permit the action.
Whether shape, size, type, context, and operation reference are valid.
Whether frequency, concurrency, repetition, and resource use stay bounded.
Whether the transition is valid for the authoritative current state.
Whether repetition could create a duplicate logical effect.
Whether activity can be investigated, corrected, and held accountable.
Protect yourself
A logo, urgent tone, copied website, account reference, case number, product tag, or sender name does not prove a request is legitimate.
Keep passwords, authentication and recovery codes, complete card credentials, and NFC cryptographic values out of ordinary messages.
Do not trust a protected-action link merely because a message looks official or urgent.
Use server-confirmed session controls when available. A support message cannot revoke or recognize a session.
A copied URL, badge, animation, or visible identifier cannot replace live tag cryptography and the protected product record.
No user impersonation
They do not take over a user's identity or ask the user to surrender the secrets that make it usable.
Public detail boundary
Public guidance should help people act safely without exposing another person, a defense, or a live vulnerability.
Security reporting boundary
A future process must define scope, safe and prohibited testing, evidence handling, contact, review, response, disclosure expectations, and legal terms. None is activated here.
Potential security concerns
Do not test a live system based on this page. No safe harbor, authorization, payment, reward, response time, disclosure date, or evidence channel is offered. Do not send secrets or exploit details through ordinary messages.
Public claim limits
zHezar is unhackable or perfectly secure.
Every attack, fraud attempt, or incident can be prevented.
NFC makes copying or counterfeiting impossible.
A support message, case reference, or sender name proves authority.
A badge, animation, hidden route, or disabled control proves authorization.
Local tests prove complete production security or monitoring.
Readiness / July 2026
This table describes current public evidence and open gates. It is not a live security dashboard, certification, audit, or incident source.
Static guidance; no certification or production-security guarantee.
Default-deny and account/session tests pass in synthetic environments.
Provider, domain, callback, and end-to-end production evidence is incomplete.
Provider enforcement, thresholds, monitoring, and emergency controls require evidence.
Validated cryptography, keys, provisioning, replay checks, and testing are required.
Staffing, alerts, runbooks, containment, notice, recovery, and regression evidence.
No report route, testing permission, safe harbor, bounty, or response promise exists.
Use current routing only
Legal & Trust shows formal document readiness. Help explains current general routing without creating a security report.