Back to site

Legal

Security

Nomi holds the record behind someone's membership card, badge or student ID, and the keys that make a credential believable. This page says plainly what protects them, what we have not built yet, and how to tell us if you find a hole.

In effect since · Codingraph S.A. · Costa Rica

Our posture

We describe here the controls that are actually in place today. Where something is a roadmap item rather than a control, we say so instead of implying a certification we do not hold: Nomi is not currently SOC 2 or ISO 27001 certified, and we will not claim otherwise on a page a customer's security team is reading.

Architecture

  • One public API. The console is a consumer of the same /v1 surface customers integrate against, using a session instead of an API key. There is no privileged side door for our own UI to grow shortcuts through.
  • Nothing authenticates in the browser. Console pages render on the server and mutations are server actions; the session is an httpOnly cookie that page scripts cannot read.
  • Credentials never reach client JavaScript. A rendered pass is streamed through a server route rather than linked to directly, so its bytes are never handed to the page.
  • Only legal actions are offered. The API returns the actions a credential's state machine allows, so the interface cannot present an operation the server would refuse — a revoked credential offers none.
  • Tenant isolation. Every record is scoped to an organisation, and every query is filtered by the organisation on the authenticated principal.

Signing material and secrets

A credential is trustworthy because of what signs it. Signing material is sealed in the database rather than left on a container filesystem, and the resolver reads the database before it looks anywhere else — a redeploy cannot silently drop a key onto disk or lose one. Secrets and platform credentials are held as environment configuration in the hosting provider, never in the repository.

API keys are stored hashed; we cannot read one back to you, and a lost key is rotated rather than recovered. Webhook payloads are signed so your endpoint can verify that a delivery came from us and has not been replayed.

Access control

  • Role-based access in the console, so an operator who issues credentials need not hold the rights that mint API keys.
  • Sign-in supports single sign-on and passkeys, and sensitive operations require a step-up re-authentication.
  • Directory-driven provisioning (SCIM and connectors) so that access follows the customer's own joiner and leaver process rather than a spreadsheet.
  • Access to production by our staff is limited to the people who need it to operate and support the platform, and is used for that purpose only.

Data protection

Traffic is encrypted in transit with TLS. Data at rest — the database and object storage — is encrypted by the infrastructure providers listed below. Uploaded artwork and photographs live in object storage rather than on an ephemeral container disk, and are served through authenticated routes rather than public URLs.

What we hold, for how long, and how it is deleted is set out in the Privacy Policy.

Audit trail

Security-relevant actions — issuing, updating, suspending, revoking, key creation, member and role changes — are recorded as events with the actor and the time, exportable from the console. Audit events are retained for up to 24 months and are not deletable from the interface; an audit trail a user can erase is not an audit trail.

Infrastructure and vendors

We run on managed infrastructure rather than machines we rack ourselves. The current providers, what each one does and where it operates are listed in the Privacy Policy, and each is bound by a written contract limiting it to our instructions. Customers may ask to be notified before a new subprocessor is appointed.

Incident response

If we become aware of a breach of security leading to the accidental or unlawful destruction, loss, alteration or unauthorised disclosure of personal data we process for a customer, we will notify that customer without undue delay and in any event within 72 hours of becoming aware, with what we know: what happened, which data and which people are affected, what we are doing, and what we recommend you do. We will keep the customer updated as the picture develops, and we will not wait for a complete picture before telling you.

Reporting a vulnerability

If you have found a security issue, tell us at security@nomi-tech.com. Include what you found, how to reproduce it, and how we can reach you. We acknowledge within 3 business days, keep you informed while we fix it, and are glad to credit you when it is resolved.

Safe harbour. We will not pursue legal action against research done in good faith under these rules: test only against accounts and data you own or have permission to use; do not access, modify, delete or exfiltrate anyone else's data; no denial of service, spam, social engineering or physical attacks; stop as soon as you have demonstrated the issue; and give us reasonable time to fix it before disclosing publicly. We do not currently run a paid bounty programme.

Your side of the line

Most incidents in a platform like this start on the customer's side. Rotate API keys when someone leaves, give Users the narrowest role that lets them work, keep your identity provider's multi-factor requirements on, verify webhook signatures rather than trusting the payload, and do not send us data the platform is not built for — the list is in clause 5 of the Terms.

No system is perfectly secure. These controls reduce risk; they do not eliminate it, and we do not represent that they do.

Contact

Security reports: security@nomi-tech.com
Abuse of the service: abuse@nomi-tech.com
Security questionnaires and due diligence: legal@nomi-tech.com