Who actually signs
At a connected device company between ten and three hundred people, the signer is the CTO or the VP of engineering. There is a firmware team that has been shipping features, a hardware team that left the debug port populated because it made bring up easier, and a cloud team that has had a penetration test and believes the product has therefore been tested. There is no product security function.
The champion is whoever is about to be asked for a document: the regulatory lead preparing a medical device submission, the EU distributor asking about the new rules, or the enterprise customer whose procurement team sent a questionnaire about the device rather than the app.
The one sentence version
Your buyer is an engineering lead with a connected product that has been penetration tested everywhere except in the firmware, and a regulator or a customer about to ask about the firmware.
The triggers, and where each one is visible
- Medical device submissions for connected devices. The FDA requires a cybersecurity package for any device with a network interface or software, including a bill of materials and a vulnerability management plan, before it will accept the submission. Device companies announce submissions and clearances, and the public clearance database names the products.
- The EU product cyber regulation. Manufacturers of connected products sold in the EU have had vulnerability reporting obligations since September 2026, with the full requirements applying from late 2027. Any company with an EU distributor or an EU product page is in scope, and the date is the trigger.
- The EU wireless product cyber requirements, in force since August 2025 for radio equipment, which reach every product with a Bluetooth or Wi-Fi chip sold in Europe.
- Vulnerability disclosures. Public vulnerability databases and the government's industrial control advisories name products and failure modes weekly. A disclosure in a category is a signal about every product in that category built on the same chip family or the same reference design.
- Connected product launches. A launch announcement naming a cloud service, an app, remote updates or a fleet dashboard is a product with an attack surface, and the launch date is public.
- Product security and firmware security job posts. A company advertising for its first product security engineer has been told to get one, usually by a customer or a regulator, and the assessment does not wait for the hire.
The regulatory dates are the two to build on. A medical device submission cannot proceed without the package, and the EU reporting duty is already in force. Both let the email name a date the reader has to meet.
Qualify in sixty seconds
- Is there firmware on a device in the field? A product that is a cloud service with a thin client is an application security engagement, not this one. A product with a microcontroller, a radio and an update mechanism is.
- Is there a regulatory or contractual date? A medical submission, an EU distributor, an enterprise customer with a device questionnaire. Any of the three sets the urgency.
- Is there a product security function in house? Check the team page for a product security title. Below a few hundred people the answer is almost always no.
- Is the trigger inside ninety days? A launch from two years ago is a product that has either been assessed or has quietly accumulated a bill of materials nobody has reviewed.
The angle that gets replies
Lead with the specific architectural question the assessment answers, in the engineer's vocabulary. Not risk, not threat, not compliance. Secure boot, the debug interface, where the keys live, and how the update is signed. The reader can answer two of those from memory and the other two will bother them.
Three openers you can adapt
- On a connected medical device with a submission planned"Saw the device is targeting submission next year. The cybersecurity package now has to include a software bill of materials and a threat model the reviewer can follow, and the two findings that most often come back as deficiencies are an unsigned update path and a populated debug interface on production units. Both are checkable in a day on a sample unit. Happy to send what the reviewer looks at first."
- On a product sold in the EU"Your product page lists EU distributors. As of this month, manufacturers of connected products sold in the EU have a duty to report actively exploited vulnerabilities on a 24 hour clock, which requires a way to know about them in the first place. Most companies at your size have not set that up. One page on what the minimum viable process looks like, attached to nothing."
- On a disclosure in their product category"A disclosure last week in your product category described a hardcoded credential in the firmware update client on a chip family close to yours. That class of issue is present in more products than get disclosed, because most are never looked at. A firmware extraction and review on one unit takes about a week and would settle it. No charge to scope."
Each one names a component, a date and a duration. It reads as one embedded engineer writing to another, which is the only voice that gets a reply in this niche.
What not to send
- "Hack proof" or "unhackable." No embedded engineer believes this and the word ends the email.
- A generic penetration test offer. "We will pen test your IoT product" describes what the large firms already did to the cloud service. The reader thinks that box is checked.
- Breach fear. "Your devices could be compromised" is true of every device ever made and carries no information about theirs.
- IT security vocabulary. Endpoints, zero trust and SIEM are words from a different discipline. Firmware, boot chain, key storage and update signing are the words that show you belong.
The objection you will hit
We already had a penetration test. Ask what was in scope. Almost always it was the cloud service and the mobile app, with the device itself listed as out of scope or tested only over the network. A firmware assessment pulls the image off the flash, reads the boot chain, probes the debug interfaces and examines how the update is verified. That is a different engagement, and the previous report's scope section will say so.
The second is our chip vendor's SDK handles security. The SDK provides the capabilities. Secure boot, encrypted storage and signed updates all exist as features that ship disabled by default, and the question is whether the product turned them on and provisioned the keys properly. Most did not.
The third is we will do it before launch. Secure boot and key provisioning are design time decisions that touch the hardware and the manufacturing line. Discovering at launch that production units ship with debug enabled is a recall, not a patch.
Deal shape
- Threat model and architecture review: commonly $10K to $30K. Fast, design phase, and the engagement that opens most relationships.
- Firmware and hardware security assessment on a sample unit: $20K to $60K depending on the device.
- Medical device cybersecurity submission package, including the bill of materials, the threat model and the vulnerability management plan: $25K to $75K.
- EU regulation readiness, including the reporting process and the documentation: $30K to $100K.
- Retainer for vulnerability monitoring and coordinated disclosure handling: $3K to $10K a month, and the reason a client acquired at the threat model stays for years.
- Signer: CTO or VP Engineering. Champion: regulatory lead or the person holding the customer questionnaire. Cycle: three to eight weeks, and days after a disclosure.
The threat model is the funnel. It is small, it is design phase, and it produces a written list of what the assessment will find, which is the assessment.
A cadence you can actually run
- Weekly, pull vulnerability disclosures and industrial advisories in the product categories you serve, and note the chip families and failure modes named.
- Weekly, pull connected product launches and medical device submissions or clearances for devices with software.
- Monthly, pull product security and firmware security job posts, and note their age.
- Quarterly, review your target list for EU distribution and flag every company that sells there against the regulation's dates.
- Qualify against the four checks, with the regulatory date first. One message per account, naming the component. Fifteen to twenty accounts a week is a full program.
- Three touches over two weeks, then stop. The next disclosure in their category is a fresh reason to write.
The regulators have published the dates and the vulnerability databases publish the failure modes. The consultancies that grow are the ones that write to the product team the week their category appears in either.
The sending mechanics most people get wrong
Everything above is about who and what. This is about how, and it is where most outbound in this niche quietly dies. Seven rules. None of them are optional.
1.Three to five sentences. That is the whole email.
Your reader is on a phone between meetings. One observable fact about their company, one consequence they have not thought about, one specific thing you would do. Anything past five sentences is a memo, and memos get archived unread.
2.Lead with a technical differentiator that turns into a number.
The messages that work best name something concrete you do differently and translate it into time or money saved. In this niche the differentiator is the firmware itself. A consultancy that extracts and reviews the image from the flash rather than testing over the network, and can say how many production devices it has found shipping with debug enabled or unsigned updates, has a finding rate no application security firm can quote. The second is the regulatory package: state how many medical device submissions your cybersecurity documentation has gone through without a deficiency.
Most services firms do not have a technical differentiator, and pretending to have one reads as exactly that. The substitute is a verticalized case study: a company like theirs, what you did, what happened, in one sentence. For this niche the line is: a 35 person connected infusion accessory company, threat model in month one, unsigned update path and populated debug header found on the sample unit, both fixed before the manufacturing line was locked, submission accepted with no cybersecurity deficiencies. The two findings and the clean review are what the reader will check.
3.Ten to twenty emails a day per mailbox. Not a hundred.
Sender reputation is scored per mailbox and per sending domain. One inbox pushing a hundred cold emails a day looks like exactly what it is, and the penalty lands on the domain, which means it lands on your client correspondence too.
If the math says you need more volume, the answer is more mailboxes on more warmed sending domains, separate from the domain you invoice from. It is never more volume per mailbox. Fifteen to twenty accounts a week at three touches is nine to twelve emails a day, one warmed mailbox. A significant disclosure in a large product category can justify writing to every maker in it that week, which is when the second mailbox is used.
4.Write ten versions of every step and test them.
Versions A through J, not A and B. Rotate subject lines and bodies. You learn which angle is actually working instead of guessing, and there is a second reason that matters more: identical bodies going out over and over is one of the patterns postmaster tools flag. Variation is a deliverability tool as much as a testing one.
Subject line seeds for this niche, each of which should become several variants: "the submission next year", "the reporting duty this month", "the disclosure in your category". Lower case, no punctuation tricks, and nothing that would look odd in a reply from a colleague.
5.Stop at three.
Most replies arrive on the first and second email. The third is already thin. Every touch past that raises the odds the whole thread gets classified as spam, and that classification follows the mailbox to the next person you write to. The long cadence is over. Three touches, each with something new in it, then leave them alone for ninety days.
6.Know what good looks like.
A one percent reply rate with a quarter of those replies positive is a healthy trigger based program. Anyone quoting you double digit reply rates is counting out of office messages or selling a course.
7.LinkedIn Sales Navigator is not optional.
Every other data source tells you who held a title at some point. Sales Navigator tells you who holds it today, because the person maintains it themselves. That is the difference between a three percent bounce rate and a fifteen percent one, and bounces are scored against the mailbox the same way spam complaints are. Verify the name there before anything goes out.
It is also the cheapest trigger detector you will own. The job change filter surfaces people who arrived in a role in the last ninety days, which is the moment they have budget and no incumbent. The posted recently filter surfaces companies talking about the exact problem you solve. Account lists with headcount growth alerts tell you who is scaling before the press release does. For this niche the saved search is headcount 10 to 300 in medical devices, IoT, industrial equipment, consumer electronics and automotive components, titles CTO, VP Engineering, Head of Firmware, Product Security Engineer and Regulatory Affairs, with the job change alert on for engineering leadership and a keyword alert on product security, firmware security and SBOM across job listings. Navigator confirms the person. The vulnerability databases, the clearance database and the companies' own distributor pages are the source.
Use it for the research and the verification, not for the message. InMail reply rates are a fraction of email, and the person who replies to a thoughtful email is the same person who ignores a connection request with a pitch attached. Pull the work email from a data provider once Navigator has confirmed the person is real and current.
None of this is specific to your niche. All of it is specific to whether anyone ever reads the angle you spent an hour getting right.
If you would rather not run it yourself
That is what we do. ExpertLayer runs this exact loop for expert led firms: the weekly disclosure and launch pull, the qualification with the regulatory date first, the angle per account naming the component, the sending across warmed mailboxes, and the reply reading. You take the conversations and do the assessment.
The first step is free and it is the same research described above. Send us your website and we will come back with 10 companies that hit these triggers right now, with the disclosure or launch, the contact, and the opening line for each.
Questions from people running this
Is the EU product cyber regulation really a live trigger already?+
As of this month, yes, in the most concrete way possible. The reporting obligations for actively exploited vulnerabilities in connected products started in September 2026, and the full requirements follow at the end of 2027. Any company shipping a connected product into the EU is now subject to a reporting duty most of them have not set up. A note that names the date is news to the majority of your prospects.
Medical devices or everything else?+
Medical devices are the best sub niche because the requirement is federal, specific and pre market: a connected device cannot be submitted without a security package. That makes the buyer, the trigger and the deliverable unusually clear. The rest of the connected product world is larger and the EU rules are pulling it in the same direction.
How do I compete with the big application security firms?+
By being about firmware and hardware, not web applications. The large firms test the cloud service and the mobile app and write firmware in the scope as an afterthought. A boutique that opens with secure boot, debug interfaces, key storage and the update path is in a conversation the large firm did not start.
Are published vulnerabilities in a competitor's product a fair trigger?+
They are the most useful one you have. A disclosure names a product category and a failure mode, and every company in that category with a similar architecture has a version of the same problem. Write to the competitors without naming the disclosed vendor, describe the class of issue, and offer to check for it.