Product authentication has a quiet dependency. Every scan resolves against a record: the batch behind a strip of tablets, the consignment behind an export carton, the procurement lot behind a transformer. Verification is only as trustworthy as the record it checks, and in regulated industries that record is itself regulated.
Most platforms ask you to upload those records to their cloud so their service can answer scans. For a consumer brand with public SKU data, that is a reasonable trade. For a pharmaceutical manufacturer, a government supplier or an exporter, it moves regulated data outside the organisation's custody. Custody is the first thing a regulator asks about.
Custody decides your audit scope
The moment product data lands in a vendor's cloud, that vendor becomes a processor of it. Your audit scope now includes their controls, their sub-processors and their retention behaviour. Residency obligations follow the data wherever the platform routes it. A breach at the vendor is a breach of your records. Each new processor adds its own agreements and its own breach notification duties to your file. Audit scope grows easily and shrinks slowly.
In regulated sectors the records at stake are heavy. Batch genealogy traces which patients received which medicine. Government supply data reveals procurement volumes and depot locations. Export documentation binds a shipment to declarations already made to customs. An organisation answers for these records by name, whoever holds the copy.
Answerability does not transfer with the data.
A vaccine batch under Schedule H2
Picture a vaccine manufacturer preparing for July 2027. Schedule H2 of the Drugs Rules 1945 has required barcodes on the top 300 pharmaceutical brands since August 2023, and the Drugs (Seventh Amendment) Rules 2026 extend the obligation to vaccines, anticancer drugs and narcotic and psychotropic drugs from 1 July 2027, with antimicrobials following on 1 July 2028. Every pack will carry a code that must resolve to genuine batch data at the moment a pharmacist or an inspector scans it.
The batch record behind that code sits inside GMP scope. It names the manufacturing site, the release tests and the responsible person. Shipping it to a third-party cloud creates a processing relationship the quality team must qualify once and then defend at every inspection afterwards. Answering the scan beside the record, on infrastructure the manufacturer already governs, creates nothing new to defend.
Government supply and export face the same test
Suppose a PSU vendor labels switchgear for a state utility. The record behind each code covers the procurement lot, the inspection certificate and the depot movement history. Many departments operate under directives that keep such data on infrastructure the state controls, and a vendor cloud in another jurisdiction fails that requirement before a single feature is compared. The procurement conversation ends at the architecture diagram.
Exporters meet the test from the opposite direction. The EU Digital Product Passport makes a battery passport mandatory from 18 February 2027, with further product categories following through 2030 under ESPR. The passport itself is public by design. The supplier data, test results and composition records feeding it are commercially sensitive, and a manufacturer will want them validated at origin, under its own control, before anything is published outward.
How validation runs inside the boundary
secQR is product intelligence and authentication infrastructure built by DBTEZ on KEZEL®, the in-boundary intelligence platform. KEZEL's rule is short: move the work, not the data. Policies define the boundary. Workflows flow to the data as encrypted instructions. Intelligence runs inside. Results remain inside and are released only under the access your policy grants.
In practice, the secQR runtime deploys where you choose: your data centre, your cloud tenancy, or an isolated tenancy we manage. Scans validate next to the record. Policy and configuration updates arrive as encrypted instructions, while product records, scan logs and analytics stay where you put them. Every validation decision lands in a tamper-evident audit trail inside the same boundary, so the evidence an inspector asks for already lives on infrastructure you govern.
The trade-off is real
The honest objection is operational weight. An API key is a faster start than a runtime in your perimeter. In-boundary deployment means your team hosts and patches a piece of infrastructure a SaaS vendor would otherwise absorb. We chose that cost deliberately. The alternative cost arrives at audit time and is paid in scope, evidence and jurisdiction rather than in engineering hours, and it recurs at every inspection for as long as the data sits outside.
So the first question to put to an authentication vendor is architectural: where does the validation decision execute, and who holds the record when the regulator calls. Every other comparison follows from that answer.
Regulatory summaries are for orientation only and are not legal advice.