The Ultimate IoT Security Checklist – 12 Essential Practices

IoT deployments are expanding rapidly, and so are the security risks. With billions of IoT devices online, enterprises and telecom operators must be proactive in fortifying their IoT solutions. Below is a guide that will help secure your IoT infrastructure against cyber threats. Use this checklist as a reference to ensure you’ve covered the critical bases of IoT security:

1. Device Security: Start at the source 

Device security is step one. If this layer fails, attackers walk past your network and cloud. Stop them at the source.

Create a unique identity for every device

Give each device its own identity. Store the private key in a secure chip such as a Secure Element, TPM, Secure Enclave, or SIM. The key stays inside that chip. The device uses it to sign challenges, but the key itself is not readable or exportable.

When it first connects, the device proves identity and software. If verified, issue a short lived token for your backend or API. Never share credentials between devices. Keep an allowlist per device so you can block or quarantine one unit without touching the rest. For rotation, create a new key on the chip and re enroll the device. Do not export or copy keys.

Only run approved software

When the device turns on, it runs only software you’ve approved and signed. If anything is altered or unsigned, it won’t run. Blocking tampered or outdated code.

Make devices that are hard to mess with

Physical access can bypass your software controls. Assume someone will try to open the case, attach a cable, or probe the board. Use sealed enclosures and tamper seals or switches. Add conformal coating where needed. Disable or remove debug ports. If the case opens or a switch trips, record it, alert your team, and put the device in a safe mode until it is checked.

Don't use default credentials

Encrypt every handshake 

Only use TLS 1.2 or 1.3 for every device connection. Each session begins by checking the server certificate. If you control both ends, pin that certificate so only the real service is accepted. Let the device prove itself too with mutual TLS where the platform allows it. Do not permit a fallback to plaintext at any step. Use keys that change per connection. If a key is compromised later, past sessions stay private. Rotate keys and certificates on a schedule. Keep clocks in sync so certificate checks pass. Allow only modern cipher suites and verify host names. Use secure defaults. MQTT over TLS at 8883, HTTPS at 443, and CoAP over DTLS at 5684.

What is the difference between TLS 1.2 and TLS 1.3? 

Each session is authenticated and encrypted. TLS 1.3 is quicker and more secure than 1.2, which needs extra round trips. When it's possible, choose 1.3 for all device traffic.

Segmentation is key

Put devices on their own VLAN (Virtual Local Area Network) or subnet. Block east to west by default. Open only what the use case needs. Use ACLs to stop device to device chatter. Route traffic through a controlled gateway. Review routes and rules on a fixed schedule. On 5G SA, isolate by slice and restrict DNNs to approved endpoints.

Firewalls and allowlists

Let devices talk only to known destinations. Block all inbound. Outbound should be a short allowlist of your backends and nothing else.

Use a proxy or firewall that filters by domain name, not just IP. APIs, MQTT, update servers, time sync. If IPs change, enforce the list at the proxy with DNS. Check both destination and port. Block all other destinations by default. Add only what the device needs.

Keep management off the public internet. If you need remote access, use a VPN or bastion with MFA. Restrict by source IP. Open it only for a maintenance window, then close it.

Block device to device traffic with ACLs. Send all device traffic through a gateway so you can log and inspect it. Rate limit per device. Cap connections and bandwidth. This stops storms and flags abuse fast. Log denies and key allows. Alert on new destinations or repeated blocks. Review rules often and remove old exceptions.

Never use old protocols

Turn off Telnet, FTP, and any open debug port. Use SSH and HTTPS instead. Remove web UIs you do not need. Disable SNMP v1 and v2c. If you must use SNMP, use v3. Close anything you do not use so scanners have nothing to hit.

Use private network paths

Keep device traffic off the public internet. Use a private APN from your carrier or a VPN that ends inside your own network. Give devices private addresses only. VPN endpoints should enforce firewall rules and logging. If you use a private APN, apply the same controls at the carrier gateway.

Detect intrusions early

Run intrusion detection on the device network to catch problems early. IDS, IPS, or NDR tools can flag: traffic spikes, port scans, odd destinations, or bursts of short connections that suggest a DDoS attack. When an alert goes off, act quickly. Isolate the device in a blocked group or cut its outbound traffic. Wait until someone reviews it.

Telco and 5G SA controls

Allow only approved APN or DNN values for each SIM and point them to your own endpoints. Separate traffic by slice so critical services stay isolated from bulk flows. Apply QoS limits on each SIM to cap bandwidth and connection bursts. These steps help contain storms, reduce fraud, and keep the network stable. For more on 5G Standalone, see here our basics guide and our deep dive.

3. Data Safety: Protect the prize

Data is the prize. Even if attackers reach your devices or network, strong protection makes the data they find useless. Keep it secure at every stage.

Keep it light

Only gather what the device needs. Drop unneeded fields and shorten IDs. Hide personal details by using random codes and rough locations. Set clear retention rules and delete data on a schedule. Apply the same rules to backups. When possible, reduce at the edge. Send summaries or ranges instead of raw data.

Encrypt and store safely

Add payload encryption on top of transport. Encrypt the message before send and decrypt only inside your backend. Use a per device or per tenant key. Encrypt data at rest with strong methods like AES-256. Use disk or database encryption and add field level encryption for the most sensitive columns. Encrypt backups and log archives. Log who read what and when.

Guard keys and integrity

Keep your keys in a secure element, TPM, enclave, SIM, or a cloud KMS. Never hardcode keys in software. Rotate them on a schedule and after any incident. In code, use a key ID and fetch the key at runtime. Do not embed the key itself. Back up keys with two person approval and test recovery. Add a hash or message authentication code to each payload and config. Verify on receipt and alert if it fails. Keep secrets and personal data out of logs.

Validate and watch the data path

Make the data you accept predictable. Define a strict schema and reject anything that does not fit. Clean inputs and convert units and timestamps before you store them. Control who can touch the data. Use roles, not shared accounts. Split read and write paths. For analytics, use read-only credentials that are short lived and expire automatically.

Then watch where data tries to go. Set per device or per tenant limits on outbound traffic. Alert on big exports, odd hours, or new destinations. In storage, add simple data loss checks that look for full IDs or secrets. These steps keep data clean on the way in and hard to leak on the way out.

Isolate tenants, respect regions, delete securely

Isolate tenants with separate storage paths and per tenant keys. Test that one tenant cannot read another. Keep data in the promised region and tag it with that region. Block cross-region copies unless approved. Delete securely with cryptographic erase and remove the encryption key so the data cannot be read. Apply the same rules to backups with clear retention windows.

4. Identity and Access: Prove it, then limit it

Identity proves who connects. Access decides what they can do. Keep both tight.

Prove the device

Give every device its own identity. Use a certificate or per device key and keep it in a secure chip. Do not let devices share a single password or key. Each device must have its own. Use mutual TLS when the platform allows it. Rotate and revoke keys when something looks off.

Secure sign-ins

Set multi-factor authentication to every human entry point, from portals to jump hosts. With passkeys or hardware keys stolen passwords become useless. Don't use SMS, these can be intercepted. Create an extra layer of MFA for important tasks like resetting keys or creating a new API token. 

Least privilege roles

Keep roles narrow so mistakes do less harm. Start with the smallest set of permissions that lets someone do the job, then add only what is missing. Remove “god” accounts. Split duties for ops, support, and admin so no single login can change everything. When extra access is needed, grant it just in time, set an end time, and record who approved it. Review roles on a schedule and take back access that is no longer used.

Sessions that expire

Treat a session as a short pass, not a lasting key. Use short-lived tokens and set idle timeouts so stale sessions die on their own. Rotate refresh tokens so long running access keeps proving itself. Where it makes sense, bind a session to the user and the device or source IP. After a password change, role change, or security incident, end every active session and make users sign in again.

Zero Trust in practice 

Do not trust by location. Check with each request that the user is who they say they are. Make sure the device is working well. Also, confirm that the role can perform that action. 
Keep systems in small zones so access never reaches farther than needed. Apply the same checks inside your network as you do at the edge. Log each allow and deny so you can see who got in, what they did and why the system allowed it.

5. Software & Firmware: Build right and patch quickly

Bad code is like a hole in your ship. One (small) hole will not sink you, but leave it too long and it becomes a breach. A strong software and update process keeps attackers out.

Build a safe update pipeline

Make updates boring and reliable. Use over the air updates so you can fix devices without touching them. Roll out in small waves. Start with a test group, then expand. Keep a one click rollback so you can go back if something breaks. Track success and failure so you spot issues early.

Patch quickly and track versions

Set clear timelines for fixes. When a new security flaw is reported publicly, handle it by risk. Patch high first, then medium, then low. Keep an inventory of versions across the fleet. Know which device runs which software version. When you find a vulnerable version, push the fix to that group and confirm it landed.

Write secure code and test

Follow the OWASP IoT Top 10. It is a short list of common mistakes to avoid. Scan code before it ships with static checks. Test running software with dynamic checks. Review code and threat model the risky parts. Remove unsafe defaults and cut dead features so there is less to attack.

Scan what you ship and what you run

Scan firmware images and container images before release. Scan endpoints on a schedule in the field. Watch for new findings as libraries age. Rebuild and redeploy instead of patching by hand.

Know what is inside

Keep a software bill of materials. It is an ingredient list for your code. Track every library and version, especially open source. Watch for new advisories. Replace or patch when a library goes bad. Check licenses so you do not create legal risk while you fix security.

6. Physical Security: Real-world defense    

If attackers can touch the box, they can bypass a lot of software controls. Lock it down in the real world.

Control the room

Protect gateways, base stations, and edge servers like you protect a data center. Put them in locked racks or cabinets. Use badge access on doors. Keep a visitor log. Add cameras where it makes sense. Limit who has keys. For field sites and POPs, use tamper-evident locks and rack doors. Disable unused console ports. Label gear clearly but never put credentials on the device. Do regular walk-throughs and asset checks so missing gear is caught fast.

Protect against the environment

Hardware fails when the environment is wrong. Use enclosures with the right rating for dust and water. Seal cable entries. Add surge protection, grounding, and a small UPS so short power cuts do not corrupt storage. Keep airflow clear. Use filters where there is dust. Monitor temperature, humidity, and vibration. Set alerts with clear thresholds so someone fixes the problem before devices cook or freeze.

Detect and respond to tampering

Make tampering obvious and noisy. Use tamper seals and case-open switches. Log every event and send an alert. For high risk devices, add a sensor mesh or conformal coating so probes cannot reach the board. If a tamper event fires, drop the device into a safe mode and:

• Remove unnecessary functions.
• Erase sensitive data from memory.
• Require a clean check or re-enrollment before going online again.

 Keep the evidence in logs so you can investigate what happened and when.

7. Cloud and Backend: Harden the brain

If the cloud side is weak, attackers skip the devices and go straight for your data. Harden the place where everything connects.

Fortify your APIs

Require strong authentication on every call. Use short lived tokens. Check permissions on each request, not just at sign in. Validate inputs and reject anything that does not match your schema. Set rate limits so a mistake or a bot cannot flood you. Use HTTPS only. Rotate tokens and client secrets on a schedule. Keep separate credentials for prod and test so one leak does not take both.

Build on strong cloud boundaries

Put services in a private VPC. Default to deny in security groups. Open only the ports you need. If an endpoint must be public, place a web application firewall in front. Use a key management service (KMS) to create and store encryption keys. No public storage buckets. Use private links or service endpoints to reach databases and queues. Keep prod and non prod in separate accounts so blast radius stays small.

Log what matters and make it stick

Record device actions, API calls, and every admin change. Centralize logs in one place. Sync time so events line up. Protect logs from edits and deletes. Alert on high risk actions like new keys, new admin users, policy changes, or bulk data exports. Keep enough history to investigate a breach, then prune on schedule.

Back-up and practice recovery

Encrypt backups. Store them in a separate account or project so a breach in prod cannot erase them. Test restore steps on a schedule. Measure how long it takes to recover and how much data you can afford to lose. Use object lock or immutability where the platform supports it. Apply the same retention rules you promised your customers.

Keep tenants apart

Treat each customer like a separate space. Use a tenant ID in every request and enforce it in code and in the database. Use per tenant encryption keys and separate schemas or databases when scale allows. Add tests that try to cross tenant boundaries and fail if they succeed. Review access paths so support tools cannot read data from the wrong tenant.

8. People and Training: Make the secure path the easy path

Most breaches start with people, not code. Help your teams choose the safe option without thinking.

Ship secure by default

Write setup guides that make secure choice the only choice. Force a unique password on first run. Turn updates on. Use HTTPS. Block old protocols. Pair the SIM to the device. Do not let anyone finish setup until these steps are done. Put a one page quick start in the box and a short checklist in the portal. Add small tips in the UI at the moment they matter, like “change the default password now” or “confirm TLS is enabled.”

Train the teams who touch devices

Keep training short and regular. Teach ops, support, and field techs how to spot phishing, handle USB drives safely, and avoid unknown Wi-Fi. Show how to use the VPN, how to log-in without shared accounts, and how to secure a laptop on site. Run simple drills. Send a test phishing email. Do a quick tabletop on a lost device. Repeat a few times a year so habits stick.

Make reporting simple and fast

Give people one easy way to report a problem. Add a button in the portal, a single email address, and a phone number. When someone reports, collect the basics automatically like device ID, time, and logs. Confirm you got it and say what happens next. Do not blame. Track how fast you triage and fix. Share the lessons so the same issue does not return.

9. Incident Response and Recovery: Contain. Eradicate. Restore.

Incidents will happen. A clear plan and the time it takes to execute will decide how much they hurt.

Write the playbook

Have an IoT specific plan before you need it. Define who leads, who isolates devices, who talks to customers, and who restores service. List the tools you use and where the runbooks live. Run short drills so the team knows the steps.

Isolate fast

When something looks wrong, stop the spread first. Quarantine the device in your CMP or move it to a blocked group. Cut outbound traffic. Suspend the SIM or revoke its data plan. Block the device’s APN or DNN so it cannot reach the network. Kill active sessions and tokens. Revoke the device certificate if you suspect keys are exposed.

Keep evidence you can trust

Good logs make the fix faster. Sync time across devices and backends. Send logs to a central place and protect them from edits. Keep enough history to see what happened and when. Tag events with device ID, SIM, user, and action. Do not wipe or power cycle a device until you capture what you need.

Rebuild clean

Restore from a golden image you trust. Reinstall approved software only. Re enroll the device with a fresh certificate or key. Rotate any secrets the device used. Run a quick health check before putting it back on the network. Watch it closely for a while.

Communicate and close the loop

Tell the right people at the right time. Internal teams first. Customers and partners if they are affected. Regulators if you must. Share what you know, what you are doing, and when you expect updates. After the incident, write a short report. Fix the root cause. Update the playbook. Run the drill again so the next one goes even faster.

10. Compliance and Standards: Make it provable

Security only counts if you can show it. Know the rules, follow a baseline, and keep proof you can hand to anyone.

Know the rules you must follow

List the laws and standards that apply to your product and region. Think GDPR for personal data in the EU. NIS2 and the Cyber Resilience Act for critical and connected products in the EU. Add any sector rules you face. Map each rule to a control and a data flow. Write down what data you collect, why you collect it, where you store it, and who can see it. Set owners for each rule so nothing is “everyone’s job.”

Use a baseline and build up

Adopt a baseline like NISTIR 8259A or ETSI EN 303 645. Treat it as the minimum, not the goal. Turn the baseline into a simple checklist for product, ops, and support. Tie it into your device requirements, your cloud setup, and your release gates. If a control is not met, the release does not ship.

Test and audit on a schedule

Bring in an independent team to check your work. Run audits and penetration tests across device, cloud, and network. Fix the findings, track them to closure, and retest. Keep copies of test reports and proof of the fixes. Short, regular checks beat one giant audit no one reads.

Trust vendors, but verify

Keep proof ready

Keep an evidence pack you can hand to a customer or regulator. Policies, training records, access reviews, risk logs, pen test reports, incident reports, and back up tests. Note who reviewed each item and when. Set reminders to refresh the pack so it never goes stale.

11. End of Life: Retire devices safely

Old devices turn into risk. End them clean so no keys, data, or access linger.

Decommission with a runbook

Use the same steps every time. Take the device off the network. Capture any logs you need for audits. Revoke its access: kill tokens, revoke the certificate, suspend the SIM, and block its APN or DNN. Remove the device from allowlists and inventory. Wipe secrets and data. If storage was encrypted, do a cryptographic erase. That means deleting the encryption key so the data cannot be read. If it was not encrypted, overwrite the drive or reset to a secure factory state. Record what you did and when, then mark the device as retired.

Set clear end of support

Publish end of support dates before you ship. Tell customers how long updates and fixes last, and what happens after. In the portal, show an end of support badge as the date nears. Offer an upgrade path or extended support if you provide it. Push a final update that helps decommission, like easier key revocation or a one click wipe. After end of support, move devices to a low trust zone or block them from new sessions so they do not weaken the fleet.

Dispose the right way

Remove and destroy any removable media and SIMs. For built-in storage, use cryptographic erase to encrypted delete data. If it is not encrypted, use a verified overwrite. If the device is leaving your control, use certified destruction or a recycling partner with a chain of custody. Keep the proof. Certificates of destruction, serial numbers, and dates. Apply the same rules to spares and returns so nothing slips back into use without a fresh, secure onboarding.

12. Monitoring and Maintenance: See it early. Fix it fast.

You cannot fix what you cannot see. Keep eyes on the fleet and make sure there is minimal time between detection and response.

Know the fleet

Track device health, software versions, configs, and usage. Send a regular status message and a short health report on a fixed schedule. Spot when settings go out of sync by checking the device against the template. Keep a live inventory of versions so you can spot old software and push updates to the right group. Flag unusual data use or connection spikes before they drive up costs or take systems offline.

Watch continuously

Send device data and logs to a central system you trust. A SIEM collects logs. A SOAR can automate common responses. Build simple behavioral baselines per device type. If a quiet sensor starts making hundreds of connections or calls a new domain name, raise an alert. Tag every event with device ID, SIM, tenant, and location so you can pivot fast.

Audit on a schedule

Run light control checks every quarter. Confirm that encryption is on, ports are closed, roles are right, and logs still flow. Do a deeper review once a year. Walk the whole chain from device to cloud to operator network. Fix gaps you find and record who fixed them and when. Small, regular audits beat one giant review no one reads.

Test like an attacker

Do real tests, not just paperwork. Penetration test: radio links, edge gateways, cloud APIs, and the operator path. Include radio frequency checks for jamming and rogue base stations if the use case needs it. Run a red team exercise that tries to move from one zone to another. Measure how far they got and how long it took you to spot them. Turn those lessons into fixes.

Alert, own, respond

Alerts need owners. Set clear on call schedules and response playbooks. An alert should say what happened, why it matters, and the first steps to take. Page the right team, not everyone. After you contain an issue, file a short report and update the runbook. Review alert rules often so false alarms drop and real issues surface first.

Bonus: Practices for Operators

Protect subscriber identities

In 5G Standalone, the permanent identifier, Subscription Permanent Identifier (SUPI), must never go over the air. Devices send the Subscription Concealed Identifier (SUCI) instead, which is the SUPI concealed with the home network public key. Keep the home network public key current and published. Verify that user equipment and the 5G core use SUCI by default. Alert and block if any clear identifiers appear, including the International Mobile Subscriber Identity (IMSI).

Set security per slice

Treat each slice like its own small network. Apply allowlists, firewalls, and rate limits per slice. Keep control and user plane endpoints tight. Log by slice and block any cross slice traffic that is not required. Use DNN allowlists so devices reach only your approved endpoints.

Govern SIMs with eUICC

Use eUICC to add, swap, and retire profiles without touching the device. Pair the IMEI to the active profile. Suspend or kill a SIM from your platform when a device is lost or abused. Track lifecycle states. Issued, active, suspended, retired. Keep an audit trail and alerts so changes are visible and fast to reverse if needed.

Make it yours

Start with this checklist and run a quick gap review. In a gap review, you compare what you do today with what the checklist expects, per device type and market. Note what is missing and what looks weak. Rank the gaps by risk and effort. Tackle the controls that cut the biggest risks first. Save the rest for later.

Set a small set of near term goals you can deliver in the upcoming weeks. Start by cutting patch time and the time it takes to isolate a bad device. Bring down certificate failure rates and false positives so the team trusts the signals. Try the changes on one device type first, measure what improves, and adjust. Repeat the review each quarter so the program keeps getting better without becoming heavy.

Why do it all yourself? 

MAVOCO enforces the rules that matter on real networks. Domain allowlists. DNN and APN locks. Slice isolation. Per-SIM rate limits. Real-time alerts with instant quarantine.

Run it your way. Clean portal for teams. Full API for automation. eUICC lifecycle built in. Per-tenant separation and reports you can hand to customers or auditors.

All of this and more. Book a live walkthrough and watch MAVOCO contain a risky device in seconds.