Security

Protections enforced where the data lives.

Supplier relationships, evidence and batch records are commercially sensitive. This page describes the protections Origentra has in place today, no more and no less.

Tenant isolation

Each organisation’s records are separated inside the database, so a fault in application code cannot expose them to another organisation.

  • Row-level security, forced on every table

    PostgreSQL row-level security is enabled and forced on every table, so its policies apply even to the table owner.

  • Composite tenant keys

    References between records, such as a batch and the lots it was made from, use keys that include the organisation, so a record can only point to records in the same organisation.

  • Least-privilege database role

    Origentra uses its own schema and a database role with no superuser rights, no ability to bypass row-level security and no ability to create objects. Columns are granted individually.

Access control

What a person can see and do depends on their role in the organisation, and is checked twice.

  • Roles

    Owner, Admin, Editor, Reviewer, Viewer. Each role grants specific permissions, checked by the application and again by the database.

  • Governed changes

    Verification states and passport publication change only through database functions that check permission and evidence, not by editing fields directly.

Accounts and sign-in

Origentra manages its own accounts, separately from any other EmKeTech product.

  • Hashed passwords

    Passwords are hashed with bcrypt and never stored in readable form. They must be at least 12 characters.

  • Hashed session tokens

    Only a keyed hash of each session token is stored, so a copy of the database cannot be used to sign in.

  • Hardened cookies

    The session cookie (origentra_session) is HttpOnly, Secure and SameSite=Lax. Sessions end after 72 hours of inactivity and after 14 days at most.

  • Rate limiting and lockout

    Sign-in attempts are rate limited, and 10 consecutive failures lock the account for 15 minutes.

  • Private password resets

    The reset form responds identically whether or not an account exists, and reset links are single-use and expire after an hour.

Private evidence files

Certificates, test reports and other evidence are held to the same access rules as the records they support.

  • Stored in the database, behind row-level security

    Files are stored inside the database under the same tenant isolation as every other record. They are never placed in a public storage bucket.

  • Short-lived signed links

    A file is served only to a signed-in member of its organisation, through a signed link that expires after 5 minutes.

  • Validated uploads

    Uploads are checked by their actual content, not just the file name, limited in size and always delivered as downloads.

Public passports

A passport is public by design, so what goes into it is decided carefully and recorded.

  • Built from an allow-list

    The database assembles each passport from fields designated as public. Internal notes, prices, quantities, logistics references, files and contact details are never read into it.

  • Versioned and hashed

    Publishing creates a new passport version. Each version is a stored snapshot with a SHA-256 content hash, and earlier versions are kept.

  • Only information that still stands

    Disputed and superseded information is left out of public passports.

  • Rate-limited public access

    Anonymous passport requests are rate limited to protect the service from abuse.

Audit and transport

Material changes leave a trace, and data is encrypted in transit.

  • Audit log

    Material actions, such as publishing a passport, changing a verification state or changing a member’s role, are recorded in an append-only audit log.

  • Encrypted connections

    The application is served only over HTTPS, and connections to the database use TLS.

  • Strict browser protections

    A Content Security Policy that allows only our own resources, refusal of framing, HTTP Strict Transport Security and a closed permissions policy.

Hosting and data location

Origentra runs in the EU, in Ireland. The full list of sub-processors is in the privacy notice.

Application
Vercel, with server functions in Dublin, Ireland
Database
PostgreSQL on Supabase, AWS eu-west-1 (Ireland)
Analytics and tracking
None. No third-party analytics or tracking scripts.
Cookies
Essential only: origentra_session for sign-in, origentra_org to remember the selected organisation and origentra_mfa during a two-factor sign-in.

What we do not claim

  • Two-factor authentication with an authenticator app is available to every account and required for EmKeTech staff, but it is not yet enforced for customer accounts, and there is no single sign-on.
  • No independent penetration test has been completed, and no security certifications are claimed.
  • Passports are versioned and hashed so a change between versions can be detected. That is a record-keeping measure, not a guarantee that information cannot be altered.

Reporting an issue

If you believe you have found a security vulnerability in Origentra, please email support@emketech.com with a description of the issue and the steps needed to reproduce it.

Please give us a reasonable opportunity to investigate and fix the issue before sharing it with anyone else, and avoid accessing or changing data that does not belong to you. The same address is the right place for security questions from customers and prospective customers.