What changed at Trinetro Labs in October 2026: authenticator sign-in and a key for every company
Two changes shipped this month that you will only notice if you go looking for them. Every customer account now signs in with an authenticator app, with an emailed code kept as a fallback, and every company's stored credentials now sit under that company's own encryption key. Neither is flashy. Both answer questions that security reviewers, auditors and careful finance teams ask before they let a new tool anywhere near their data.
Trinetro Labs · Published 25 October 2026 · 5 min read
What changed this month
Here is the short version, in the order you would meet it.
- Authenticator app at sign-in. Every customer account sets up an authenticator app once, then types its six-digit code each time it signs in. The emailed code is still there for the day the phone is not to hand.
- A key for each company. Stored credentials, files and saved sessions are encrypted with AES-256, and each company now has its own encryption key. Deleting a company destroys its key.
- A free eBook library. The eBooks section opened with its first title, a practical framework for auditing your data stack and choosing the quick wins. It is a free PDF, with no sign-up.
Nothing about how answers are computed changed. TEI still resolves terms, joins and metrics with deterministic logic, so the same question returns the same answer. These changes sit around the engine: who gets in, and how what they bring with them is protected.
Why an authenticator app, and why email stays as a fallback
A password on its own fails the way passwords always fail: it gets reused, shared in a chat, or typed into a look-alike page. A code sent by email is better, but it is only as safe as the mailbox it lands in. An authenticator app generates its code on the phone itself, from a secret shared once at set-up, so there is nothing to intercept in transit. The reason the emailed code stays is practical. Phones get lost, and a sign-in method nobody can recover is its own kind of outage. We would rather have a weaker route that exists than a stronger one that locks a finance team out on the day of a board pack. So the recovery path is deliberate and short:
- At set-up you are shown ten one-time recovery codes, once. Each works a single time.
- If the phone is lost, a recovery code or the emailed code gets you in.
- If an admin removes a member's authenticator, that person signs in with an emailed code until they set it up again. You can also generate a fresh set of recovery codes from your account at any time.
Why one key per company
With one key for every customer, a single mistake exposes everyone. With a key per company, the damage from a problem is limited to the one company it touches. That is the whole idea, and it is worth being plain about its limits. A separate key narrows the blast radius; it does not replace access control. Who can see which numbers is still decided by the permissions you set, and the data access control checklist is the place to start if you have not reviewed them lately. There is a second benefit that matters at the end of a relationship. When a company is deleted, its key is destroyed with it, and what was encrypted under that key can no longer be read. The Security page lists the controls we describe publicly, so you can compare them with this post.
Five questions to ask any analytics vendor
You do not need to be a security engineer to review a tool that will touch your books. These five questions separate a considered answer from a brochure:
- Is a second factor compulsory for every user, or optional, or only for admins?
- What happens when someone loses their phone, and who is allowed to reset them?
- Are customers' stored credentials encrypted under one shared key, or one key per customer?
- What happens to a customer's key and data when the contract ends?
- Can you see who gave access to whom, or only who has it today?
A good vendor answers the first four in a sentence each. The fifth is the easiest to skip, and it is the one auditors tend to press on when something has gone wrong. The system invariants post explains how we think about the rules that never bend.
Where the DPDP Rules fit
India's Digital Personal Data Protection Rules were notified in November 2025, with obligations phased in over roughly 18 months, so full application falls in 2027. Read the official text for the dates that apply to your business, because different provisions start at different points. Whatever your timetable, reasonable security safeguards are where a review begins, and a compulsory second factor and separate encryption keys are the kind of safeguard that is easy to evidence when someone asks.
Frequently asked questions
Is the authenticator app compulsory for every user?
Yes, for every customer account. Each one sets up an authenticator app at sign-in and then uses its code each time. The emailed code stays available as a fallback if you cannot reach the app. The guided demo, which uses made-up sample accounts, is the one exception.
What if I lose my phone?
Sign in with one of your ten recovery codes, each of which works once, or ask for an emailed code. If you belong to a team, an admin can also remove your authenticator, and you then sign in by email until you set it up again.
What does a separate encryption key for each company change?
It limits the effect of a problem to one company instead of all of them, and it means a deleted company's key is destroyed with it. It does not replace permissions: who can see which data is still controlled by the access you set.
Did anything change in how Trinetro computes answers?
No. The engine still resolves terms, joins and metrics with deterministic logic, so the same question returns the same answer. These changes cover sign-in and key handling around the engine.