Mirai Is Ten Years Old. IoT Interview Questions Have Not Caught Up.

In October 2016, the Mirai botnet took down a significant chunk of the internet by compromising roughly 600,000 IoT (Internet of Things) devices. The attack vector was not a sophisticated zero-day. It was default credentials. Cameras, DVRs, and routers shipped with factory usernames and passwords that users never changed and, in many cases, could not change. The devices had no update mechanism, no security monitoring, and no way to recover once compromised.

Mirai is almost a decade old now, but the constraints it exploited have not gone away. They are fundamental to IoT security, and they are exactly what interviewers want you to understand. A web application can be patched in minutes. A firmware update on 50,000 devices deployed across hospital networks is a logistics operation that takes months. The security decisions you make at design time follow that device for its entire operational life.

Why IoT security is a different discipline

When an interviewer asks "How would you approach securing a medical device that will be deployed in hospitals for the next ten years?", they are not asking about JTAG or UART. They are asking whether you understand the problem space.

Candidates who jump straight into firmware extraction and vulnerability assessment are answering a different question. Assessment is one activity within IoT security. The role itself is about making design decisions under constraints that traditional IT security does not face.

Three constraints define the discipline:

You cannot patch easily. Some devices have no remote update capability. Others have update mechanisms that require physical access, scheduled maintenance windows, or regulatory re-certification after changes. A vulnerability discovered two years post-deployment might remain unpatched for months, or forever.

Physical access is a given. Unlike servers in a locked data center, IoT devices are often deployed in locations where adversaries can physically interact with them. Debug interfaces (JTAG, UART), removable storage, and exposed hardware components are all part of the attack surface.

The supply chain is opaque. The firmware running on a device is not written entirely by the vendor. It includes open-source components, third-party SDKs, chipset firmware from the silicon vendor, and sometimes components the vendor does not fully understand. A vulnerability in a library three layers deep in the dependency chain is still your problem.

Security decisions sorted by reversibility

One of the most useful frameworks for IoT security interviews is sorting design decisions by how reversible they are after deployment. This shapes where you invest design attention and where interviewers expect depth.

Irreversible at deployment. Hardware security features like Secure Boot, hardware roots of trust, and physical debug interface disablement. The initial key provisioning process falls here too. Getting these wrong means you either cannot fix it without a hardware revision or you accept the weakness for the device's entire life. A real example: Secure Boot keys provisioned using a script that pulled from a shared network drive, no HSM, no access controls. If those keys were compromised, every device ever manufactured with them was permanently untrustworthy.

Expensive to change. The firmware update architecture, including how updates are authenticated, delivered, and applied. A device with a weak update mechanism that is already deployed creates a painful paradox: fixing the update mechanism requires pushing an update through the very system you cannot trust. This connects to the same lifecycle thinking that OT/ICS security professionals deal with in SCADA environments, where SCADA means supervisory control and data acquisition systems.

Operational. Configuration, certificates, network segmentation, and monitoring. These can be adjusted after deployment but require operational investment and coordination with device owners who may not prioritize security.

Interviewers want to hear you reason about this hierarchy. A candidate who spends equal time on every security control has not internalized what makes IoT different.

Firmware analysis: what you are actually looking for

When interviewers ask about firmware analysis, they want to understand your analytical process, not just confirm you know which extraction tools exist.

Extracting and unpacking. Understanding the filesystem structure, identifying the OS and libraries, noting version numbers that can be checked against known vulnerability databases. The structure itself tells you things: is this a stripped-down RTOS or a full Linux distribution with services the device probably does not need?

Hunting for hardcoded secrets. Credentials, API keys, and cryptographic keys appear in IoT firmware with surprising frequency. These cannot be rotated after deployment without a firmware update, which is why they are high-severity findings. Run strings, grep for common patterns, check configuration files. The basics catch a remarkable amount.

Evaluating cryptographic implementations. Weak or custom cryptography, outdated TLS versions, disabled certificate validation. These are common in embedded systems where developers work under resource constraints and sometimes copy-paste from Stack Overflow examples that prioritize "make it work" over "make it secure."

Understanding the update mechanism. How does the device verify a firmware update is legitimate? Is the signature check correct and complete? Can an attacker roll back to an older vulnerable version? What happens if an update fails partway through?

Mapping the network attack surface. What services are listening? What protocols are used? Are there undocumented administrative interfaces left over from development? The network defense principles that apply to traditional infrastructure apply here too, but with tighter constraints on what you can monitor and control.

The update mechanism deep-dive

Interviewers frequently drill into firmware updates because this single mechanism determines whether every other security investment remains viable over time.

Strong answers address the full chain of trust: Who holds the signing keys, and how are they protected? Is the signature verification on the device side correct and covering the entire image? Can an attacker deliver a partial update or manipulate the process to get the device into an insecure state? Have downgrade attacks been considered?

The delivery mechanism matters too. Pull-based models (device checks for updates) require the device to authenticate the update server and resist DNS manipulation. Push-based models (vendor pushes to devices) require strong device authentication on the vendor side.

And then there is the failure scenario. Interrupted updates are a real attack vector. If the device ends up with a partially applied firmware image, does it fall back to a verified good state, or does it brick, or (worst case) drop into an insecure recovery mode?

Supply chain: what separates senior candidates

One area that consistently distinguishes senior IoT security candidates in interviews is supply chain thinking. Strong candidates ask:

• Does the vendor maintain a software bill of materials (SBOM) for the firmware?
• How do they track CVEs in third-party components?
• What happens when a vulnerability is found in a dependency the vendor did not write?
• Are there components that cannot be updated because they require chipset firmware from a supplier who may no longer support the hardware?

These questions reflect the reality that IoT vulnerability management is often a supply chain problem. The same thinking applies to mobile security assessments, where third-party SDKs bundled into apps introduce risks the developer never audited.

Build a lab to practice

If you want to develop hands-on IoT security skills, a few affordable options:

Grab a cheap router or IP camera. Older consumer devices are inexpensive and often have extractable firmware, default credentials, and debug interfaces. Practice the full analysis workflow on real hardware.

Use firmware samples from public sources. Many vendors host firmware downloads publicly. Extract, unpack, and analyze them even without the physical device.

Set up an emulation environment. Tools like QEMU and Firmadyne let you emulate extracted firmware and interact with the running system without the physical hardware.

Practice the update mechanism review. Download firmware updates from a vendor, examine the update package format, check for signatures, and evaluate what protections exist against tampering.

Red flags interviewers watch for

Assessment-only thinking. Candidates who can find vulnerabilities but have not thought about preventing them or responding to them in a deployed fleet are not ready for design review or product security roles.

Ignoring operational constraints. Recommending monthly offline patching for a device in a water treatment facility demonstrates that you have not thought about operational reality.

No mention of key management. Cryptography is only as strong as its key management. Answers that mention encryption without discussing how keys are generated, stored, and rotated are incomplete.

Generic IT security recommendations. "Patch regularly" and "use strong passwords" are not useful when patching requires a field maintenance visit and the device may not have a user authentication model at all.

IoT security interview questions on MyKareer focus on the constraints that make this domain unique. Practice free.