Security Built Into Every Connection

1. HOW MICROCHIP CONNECT CONNECTS SYSTEMS

Microchip Connect provides controlled, authorised connections between the organisations and systems involved in supplying, implanting and registering individual microchips.

Microchip allocation information is received through authorised system connections and associated with the relevant Microchip Company and Veterinary Practice.

Registration information moves through controlled connections between the Veterinary Practice, Microchip Connect and the relevant participating Microchip Database.

2. ALL SYSTEM ACCESS MUST BE AUTHORISED

Participating organisations are responsible for providing the access, credentials, documentation and permissions reasonably required for their authorised integration.

3. PROTECTED ACCOUNT ACCESS

Microchip Connect accounts are intended to be accessible only by authorised users and systems.

Security principles applied to accounts may include:

• authenticated login;
• controlled account activation;
• role-based permissions;
• tenant separation;
• restricted administrative access;
• credential management;
• and account suspension where security requires it.

Where a control is described as a design principle rather than a confirmed implemented feature, it is stated as something the platform is designed to do.

4. CONTROLLED ACCOUNT ACTIVATION

Microchip Connect uses Account Numbers and Activation Keys for initial account activation.

Activation credentials are separate from permanent system-to-system API credentials.

Activation Keys should be:

• securely generated;
• single-use;
• capable of expiry;
• invalidated after successful activation;
• and not reused as permanent API credentials.

5. PRACTICE IDENTIFICATION USING ACCOUNT NUMBERS

Every Veterinary Practice in Microchip Connect has a unique Practice Account Number using the format three letters + three numbers.

The Practice Account Number is the principal business identifier for the practice.

Practice Name, Postcode, Address, Email and Telephone may be used to help identify or verify a practice, but should not replace the Practice Account Number once established.

Using a stable Practice Account Number helps reduce the risk of allocations or registrations being associated with the wrong practice.

6. COMPANY DATA IS SEGREGATED

Microchip Connect is designed as a multi-tenant platform supporting multiple Microchip Suppliers and Microchip Databases.

Each Microchip Company account should only be able to access information appropriate to that organisation, its users, its integrations and its authorised functions.

Company A must not be able to access Company B’s restricted commercial, allocation, registration, billing or integration information.

Access restrictions should not rely solely on hiding data in the front end; data access should also be restricted at the application and data-access layer.

7. ACCESS BASED ON ROLE

Different users require different levels of access.

Access should follow the principle of least privilege. Not every user should hold administrator access.

8. SECURE API & INTEGRATION CONNECTIONS

Microchip Connect uses separate system-to-system credentials for authorised integrations.

9. AUTHENTICATED IDENTITY TAKES PRIORITY

Microchip Connect must not rely solely on an Account Number submitted in an API payload to determine which organisation is making the request.

The authenticated integration identity must be authoritative.

10. SUPPLIER CONNECTIONS ARE LIMITED TO THE REQUIRED FUNCTION

Where a Microchip Supplier connects its stock, sales, order or dispatch system to Microchip Connect, the connection should be limited to the authorised information required for microchip allocation and related functions.

• microchip numbers;
• batch;
• supplier reference;
• Practice Account Number;
• practice details where required;
• dispatch reference;
• allocation date;
• and associated database information.

Microchip Connect does not require unrestricted access to unrelated supplier information.

11. CONTROLLED DATABASE INTEGRATION

Where a Microchip Database connects to Microchip Connect, access should be limited to the authorised functions needed to support the registration workflow.

• registration submission;
• validation;
• customer acceptance status;
• Smart Tag activation decision notifications;
• registration status;
• account creation/update functions where authorised;
• registration confirmation;
• and technical error responses.

The destination Microchip Database remains responsible for its own security, registration rules and final registration record.

11A. PROTECTING SMART TAG PAIRING AND ACTIVATION DECISIONS

Where a Smart Tag has been paired to an individual microchip before supply, that pairing is treated as part of the microchip’s recorded provenance and is protected by the same authenticated connection, tenant separation and audit controls.

• Smart Tag pairing is submitted through an authenticated supplier connection only.
• A Smart Tag follows the microchip’s recorded allocation and cannot be reassigned to another company’s microchip.
• Pairing requests are protected against duplicate processing.
• The customer’s Smart Tag activation decision — accepted, declined or deferred — is recorded once and can be audited.
• Notification of that decision to the destination Microchip Database is logged, and failed notifications can be retried safely.

Microchip Connect does not collect Smart Tag subscription payments. Where the customer accepts, the destination Microchip Database is informed that subscription or payment setup is required and remains responsible for that process.

12. PROTECTING MICROCHIP SUPPLY PROVENANCE

Microchip allocation history is fundamental to Microchip Connect.

Important provenance information should not be silently overwritten.

If a microchip is returned, reallocated or moved between practices, the previous history should remain auditable where required.

13. THE COMPLETE MICROCHIP NUMBER MATTERS

Microchip Connect should use the complete individual microchip identifier together with its recorded allocation history.

The first three digits alone must not be used as the security or routing key. It should not be assumed that a given prefix belongs to a single database — different companies may supply microchips sharing the same general prefix.

14. PROTECTING INFORMATION WHILE IT MOVES

Microchip Connect connections should use appropriate secure, authenticated communication when exchanging information between participating systems.

Specific transport standards, cipher suites and certificate details are not published on this page.

15. PROTECTING STORED INFORMATION

Information stored by Microchip Connect should be protected through appropriate technical and organisational controls, which may include:

• access restrictions;
• tenant isolation;
• role permissions;
• authentication;
• audit controls;
• secure credential handling;
• and backup protection.

16. ONLY PROCESS THE INFORMATION REQUIRED

Microchip Connect should process only the information reasonably required for microchip allocation, registration, account administration, security, billing, audit or another defined lawful purpose.

The Supplier Allocation API should not require keeper or pet information simply to record which microchips have been supplied to a Veterinary Practice.

17. REGISTRATION DATA IS RESTRICTED

Keeper and pet information may be processed where it is required to support microchip registration.

Supplier users should not receive unrestricted access to keeper personal information merely because their company supplied the microchip. Access must be based on an authorised function and lawful purpose.

18. CUSTOMER ACCEPTANCE CAN BE AUDITED

Where a destination database requires keeper acceptance:

Microchip Connect may retain:

• request status;
• acceptance status;
• refusal status;
• date/time;
• and relevant Registration Transaction reference.

Customer acceptance of registration must not automatically be treated as marketing consent.

19. ONE REGISTRATION TRANSACTION — NO DUPLICATE PROCESSING

A registration may involve several API communications.

One Registration Transaction

Technical retries must not create duplicate Registration Transactions or duplicate billable transactions. Transaction identifiers, idempotency controls and duplicate detection should be used where implemented.

20. SAFE RETRIES

Supplier and database systems may retry requests when a response is not received. Microchip Connect should recognise repeated requests representing the same event.

This is especially important for microchip allocations, registration submissions and billing events.

21. IMPORTANT ACTIVITY IS AUDITABLE

Where implemented, Microchip Connect should maintain records of important events such as: account created; account activated; login; API credential created; credential rotated; credential revoked; allocation received; practice identified; practice match exception; allocation changed; registration submitted; customer action requested; registration completed; registration failed; account suspended; administrative change; and security events.

Audit information may include timestamp; account; user or system; event; status; relevant microchip; relevant Practice Account Number; and transaction reference.

Usable secrets should not be recorded in audit logs.

22. WHEN SOMETHING DOES NOT MATCH, STOP AND INVESTIGATE

Microchip Connect should not guess where important identity or allocation information is uncertain.

In these situations an exception should be created rather than silently continuing with an uncertain result.

23. AVOIDING INCORRECT PRACTICE ALLOCATION

Practice identification priority should be:

1. Practice Account Number;
2. existing supplier customer mapping;
3. practice search;
4. exception.

Where practice matching is required, strong signals such as Practice Name plus Postcode should be used, with supporting information such as address, email and telephone.

An uncertain practice should not be selected automatically on the basis of name alone.

24. MONITORING IMPORTANT PLATFORM EVENTS

Microchip Connect should monitor important security and operational signals where implemented, for example: repeated authentication failures; suspicious API activity; unexpected cross-tenant access attempts; integration failures; high exception volumes; credential misuse; privileged administrative activity; and system errors.

Why Go Digital Ltd does not claim 24/7 human security monitoring, a Security Operations Centre, or real-time human threat response.

25. PROTECTING CREDENTIALS

API secrets should not be displayed after their authorised initial display except where the system securely supports recovery.

Credentials should be:

• revocable;
• rotatable;
• associated with the correct account;
• protected from unauthorised disclosure;
• and excluded from ordinary logs.

Activation Keys should become invalid after successful activation.

26. SECURITY SUSPENSION

Why Go Digital Ltd may suspend access where reasonably necessary because of suspected misuse; unauthorised activity; credential compromise; material security risk; repeated attack behaviour; non-payment where applicable; or breach of the Terms & Conditions.

Suspension may include:

• user login disabled;
• API credentials revoked;
• integration access blocked;
• and account functionality restricted.

27. SECURITY CONTINUES THROUGHOUT DATA RETENTION

Information retained by Microchip Connect remains subject to access, security and retention controls throughout its retention period.

• retain only where justified;
• restrict access;
• delete or anonymise when no longer required;
• preserve necessary provenance;
• maintain appropriate audit information.

28. BACKUP & RECOVERY PROTECTION

Microchip Connect may maintain backup copies for resilience and disaster recovery.

Backup information should be protected and subject to the applicable retention schedule. Backup periods are set out in the Data Retention & Deletion Policy rather than duplicated here.

29. SECURITY INCIDENT RESPONSE

Why Go Digital Ltd will investigate suspected security incidents and personal-data breaches affecting Microchip Connect.

Where required by applicable law, Why Go Digital Ltd may notify:

• relevant Data Controllers;
• the Information Commissioner’s Office;
• and affected individuals.

Participating organisations must notify Why Go Digital Ltd promptly where they become aware of an incident affecting Microchip Connect data; integration credentials; connected systems; or authorised APIs.

30. CONNECTED SYSTEMS HAVE THEIR OWN SECURITY RESPONSIBILITIES

Microchip Connect depends on participating organisations maintaining secure and functional systems, including supplier software; Veterinary Practice systems; PMS platforms; Microchip Databases; hosting infrastructure; and other connected services.

Why Go Digital Ltd cannot control the security of an independent organisation’s entire system. Each participating organisation remains responsible for protecting its own environment; authorised access; credential handling; staff access; malware protection; system maintenance; and compliance with its own security obligations.

31. SECURITY SUPPORTS DATA PROTECTION

Security measures should support Microchip Connect’s obligations under:

• UK GDPR;
• Data Protection Act 2018;
• and other applicable UK data-protection law.

32. SECURITY FAQ

33. REPORT A SECURITY CONCERN