Product Security

Teradyne is committed to delivering secure, reliable products that help customers operate with confidence. Security is embedded throughout our product lifecycle, from secure design and development to continuous vulnerability assessment and mitigation. Guided by industry-recognized frameworks and rigorous governance, our Product Security Program helps safeguard data, protect critical operations, and address emerging cybersecurity risks. By integrating security, privacy, and responsible technology practices into everything we build, we support the trust our customers place in Teradyne every day.

Report a security vulnerability

Teradyne builds automated test equipment and robotics that customers depend on in production environments. If you have found a security vulnerability in one of our products, we want to hear from you. This page explains what to report, how to report it, and what happens next.

Submit a vulnerability report

Secure intake form. No account required.

How to report
Our secure online intake form, the single channel for vulnerability reports.
Acknowledgement
Automated confirmation with a Tracking ID immediately on submission.
Who handles it
A named contact from the product security team that owns the affected product.
Cost to you
Reporting is free. Teradyne does not operate a paid bug bounty programme.

Our commitment to you

Teradyne operates a Coordinated Vulnerability Disclosure (CVD) process, run by our Product Security Incident Response Team (PSIRT). When you report a vulnerability to us in good faith, we commit to the following.

We will respond

Every report receives an automated acknowledgement with a Tracking ID. A member of our Product Security team then reviews it and follows up with you directly.

We will keep you informed

Once we have assessed your report, we will tell you whether we have reproduced the issue, how we have rated it, and what we intend to do about it.

We will not pursue you

If you follow the rules of engagement below, we will treat your research as authorised and will not initiate legal action or a law enforcement referral against you. See Safe harbour.

We will credit you

Where you would like it, and where a public advisory is issued, we are glad to credit you by name or handle. You may also ask to remain anonymous.

What is in scope

This process covers security vulnerabilities in Teradyne products and the software and systems that ship with them, across all of our business units. Examples include:

  • Semiconductor Test: UltraFLEX and UltraFLEXplus, J750 and IP750Ex, Magnum memory test, ETS and SLIC precision power and analog test, Titan, TitanHP and Mercury HDD test systems, and Saturn storage test systems.
  • Product Test: TestStation and Omnyx production board test, Photon silicon photonics test, and the Spectrum, VICTORY, GENEVA, TestStudio and related defence and aerospace test platforms.
  • Robotics: Universal Robots collaborative robots and Mobile Industrial Robots autonomous mobile robots. Reports for these brands are welcome here and are routed to the relevant team, or you can use the Universal Robots and Mobile Industrial Robots pages.
  • Wireless test: LitePoint IQxel, IQgig, IQxstream, IQcell and IQfr test systems, and IQfact+ software. See also the LitePoint page.
  • Embedded and controller software: instrument firmware, test executives, runtime and control software, and the operating system images and service configurations we supply as part of a system.
  • Teradyne operated internet facing services: websites, customer portals and support systems operated by Teradyne.

These are examples, not a complete list. Our portfolio changes over time, so if your finding affects a Teradyne product that is not named here, please submit it anyway and name the product in the form. We will route it to the right team.

What is out of scope

The following are generally not accepted. We may still review a report in this list if you can demonstrate concrete security impact, so if you are in doubt, submit it and tell us why it matters.

  • Raw output from an automated scanner with no demonstrated exploitability or impact.
  • Missing HTTP security headers, cookie flags, TLS configuration preferences, or SPF/DKIM/DMARC findings with no demonstrated impact.
  • Self-XSS, clickjacking on pages with no sensitive action, and issues that require a fully compromised or physically dismantled device the reporter already controls.
  • Denial of service, volumetric, load or stress testing of any kind.
  • Social engineering, phishing, or physical intrusion against Teradyne employees, customers, offices or facilities.
  • Vulnerabilities in third party products or services we do not control. Please report those to the relevant vendor, and tell us if a Teradyne product is affected as a result.
  • Products that have reached end of support, unless the issue also affects a supported release.
  • Reports that consist only of a version number matched against a public CVE list, with no analysis of whether the affected code path is reachable in our product.

Rules of engagement

Our products operate industrial machinery, robots and high value test cells. Testing them carelessly can injure people and destroy equipment. Please observe the following.

Never test against equipment in productive use. Do not test on any machine that is running a live production workload, and never on a robot or test cell that is not in a secured, unoccupied test environment under your own control. Do not attempt to disable, bypass or measure the response of functional safety systems, emergency stops or protective stops.

  • Test only on equipment you own, or for which you have the documented, explicit permission of the owner. Never test on a Teradyne customer's equipment.
  • Stay within scope. Do not pivot to other systems, networks or accounts.
  • Use only the minimum access needed to demonstrate the issue. Stop as soon as you have proven it, and do not attempt to escalate further.
  • Do not access, copy, modify or destroy data that is not yours. If you encounter personal data, customer data or credentials, stop immediately, do not retain a copy, and tell us in your report.
  • Do not degrade, interrupt or damage any service, system or piece of equipment.
  • Report the issue to us promptly after discovery, and give us a reasonable opportunity to remediate before disclosing it publicly.
  • Keep the details confidential between you and Teradyne until we have jointly agreed that it is appropriate to publish.
  • Do not use your findings, or the fact of your access, to demand payment. Reports submitted with a payment demand attached are handled as extortion, not research.

Safe harbour

If you make a good faith effort to comply with this policy during your research, Teradyne will consider your activity authorised. We will not initiate or support legal action against you, or refer you to law enforcement, in connection with research conducted in accordance with this policy. If a third party brings legal action against you for research that complied with this policy, we will make that compliance known.

This policy does not give you permission to act on any network or system belonging to a third party, including our customers and suppliers, and it does not waive any obligation you have under applicable law. If you are unsure whether something you plan to do is permitted, ask us first through the form before you do it.

What to include in your report

The intake form walks you through six short sections. The more precise you are, the faster we can reproduce the issue and route it to the engineers who own the affected code. Please have the following ready.

1. About you

Your name or handle, and an email address we can reply to. An organisation name is optional, and so is a PGP public key if you would like our follow-up encrypted.

2. Affected product

The product, system or service affected, the specific version, build or component, and the URL, IP address, hostname or interface where you found the issue. This is what determines which product security team receives your report.

3. The vulnerability

The vulnerability class, a CVE identifier if one already exists, and a technical description of the flaw: the vulnerable component, the root cause, and the conditions under which it triggers.

4. Proof and reproduction

Numbered, self-contained steps that let an engineer reproduce the issue from a clean installation, plus any proof of concept request, payload, script or configuration.

5. Impact

What an attacker gains, and what they need first: network position, a valid account, administrative rights, physical access, a specific race condition. Both directly affect how we prioritise the fix.

6. Exposure and disclosure

Whether you have seen the issue being exploited, whether any part of it is already public, any disclosure deadline you are working to, and anything else we should know.

Attachments

You can attach supporting evidence: screenshots, logs, packet captures, crash dumps, or proof of concept code. The form accepts .txt, .py, .js, .html, .pdf, .png, .jpg, .jpeg, .gif, .pcap, .cap, .zip, .tar and .gz files. Every attachment is scanned for malware on arrival. Please redact any third party personal data before you upload, and never include live customer data.

What happens after you submit

  1. You get a Tracking ID

    As soon as your report is received you get an automated confirmation email with a Tracking ID. Quote it in any follow-up so we can find your report instantly.

  2. We triage and route it

    Your report is assessed for severity and regulatory significance, then routed to the product security team that owns the affected product. A named contact from that team picks it up.

  3. We validate and rate it

    Our engineers attempt to reproduce the issue and assign a severity using CVSS. We will come back to you if we need more detail, and we will tell you the outcome of the assessment, including if we conclude it is not a vulnerability, and why.

  4. We remediate

    Confirmed issues are tracked to a fix in our engineering systems. Timelines depend on severity and on the release and qualification cycle of the affected product. For industrial and safety related equipment, a fix must be validated before it ships. We will keep you updated on progress.

  5. We disclose together

    Where appropriate we publish an advisory and, if applicable, request a CVE identifier. We coordinate timing with you and credit you as you prefer. If we are required to notify a regulator or a CSIRT, we will do so and let you know.

If this is not a product vulnerability

Please use the right channel so your issue reaches the right people. This process is only for suspected security vulnerabilities.

  • A non-security product fault, or you need help with a product: contact Teradyne support through your usual support channel.
  • A commercial, sales or general enquiry: use the contact options elsewhere on this website.
  • A suspected security incident affecting your own Teradyne equipment: contact your Teradyne support representative immediately, and tell them you believe it is a security incident.
  • A phishing email, or a website impersonating Teradyne: report it through the form and select information disclosure or security misconfiguration. Do not interact with the message further.

Ready to report?

The form takes about ten minutes if you have your reproduction steps and evidence to hand. It is submitted over an encrypted connection directly to Teradyne Product Security.

Submit a vulnerability report

By submitting a report you confirm that you have read and will follow this policy, and you agree that Teradyne may use the information you provide to investigate and remediate the issue, and to notify affected customers, partners and regulators as required. Your report is handled confidentially by our Product Security team.

Teradyne does not operate a paid bug bounty programme and does not offer monetary rewards for vulnerability reports.

Teradyne Coordinated Vulnerability Disclosure policy. Effective August 26, 2026. We may update this policy; the version published here at the time you begin your research is the one that applies.