Security built for enforceable unit truth.
TRU is designed to resist the failure modes that break static identifiers: copying, replay-style abuse, swapping, and spoofing — while keeping sensitive implementation details off public pages.
This page is intentionally high-level. Deeper security architecture, key handling, and binding methods are provided during the demo process under NDA.
Security pillars
The goal is simple: verified units, enforceable outcomes, and defensible signals — without leaking secrets.
TRU is built to make unit truth enforceable without exposing sensitive implementation details on public pages.
- • Controlled disclosure: deep technical/security brief shared during demo under NDA
- • Verification logic lives on the rail (not on the tag)
- • Unit identity designed to persist beyond custody
TRU is designed to resist common real-world attack patterns that break static identifiers.
- • Copying and cloning attempts
- • Replay-style behaviors (re-using observed identifiers)
- • Swap attacks (moving valid identifiers to wrong units)
- • Spoofing attempts against verification flow
TRU is designed to minimize data collection and keep sensitive details scoped to what's needed for verification outcomes.
- • Outcome-first: return clear results without requiring personal data
- • Event trails can be enabled/disabled and scoped by deployment
- • Retention aligned to customer policy and operational needs
TRU supports role-based access and environment separation for operational control and auditability.
- • Role-based access (least privilege)
- • Environment separation (dev/stage/prod)
- • Administrative actions can be audited (deployment-dependent)
Sensitive keys and binding methods are kept out of public materials. The rail is built to keep secrets server-side and reduce exposure risk.
- • Secrets are not stored in public-facing pages or client code
- • Key handling and rotation discussed in security brief
- • Tag binding methods disclosed under NDA only
Security is not just cryptography—it's operational control: issuance discipline, verification enforcement, and measurable signals.
- • Controlled issuance model (who can encode and where)
- • Verification at critical touchpoints (desk, dock, service, resale)
- • Event signals that expose fraud clusters and channel leakage
Threat model (what TRU is built to stop)
These are the most common ways unit verification systems fail in the wild.
- • Copying: duplicating identifiers or labels
- • Replay: re-using observed identifiers to simulate legitimacy
- • Swapping: moving valid identifiers onto different units
- • Spoofing: attempting to fake verification outcomes
- • Operational bypass: encoding/issuance drift and uncontrolled touchpoints
What TRU does not claim
Clarity matters. Security pages lose credibility when they overpromise.
- • TRU does not claim 'perfect security.' It claims enforceable unit truth and measurable risk reduction.
- • TRU is not a static ID scheme. Enforcement happens on the rail with context and rules.
- • TRU is not a marketing QR program. It is identity + verification + outcomes.
Need the security brief?
We'll share architecture details, key handling approach, and binding model under NDA as part of the demo process.