Securing the Factory: Why TARA Matters in Industrial IoT

Securing the Factory: Why TARA Matters in Industrial IoT

‍

Introduction

Industrial IoT (IIoT) powers modern factories, plants, and smart grids by connecting machines, sensors, robots, and control systems. This connectivity brings speed, flexibility, and efficiency—but it also opens the door to cyber threats.

A single weak point can:

• Shut down production lines
• Damage critical equipment or raw materials
• Leak trade secrets or operational data
• Put worker safety at risk

That’s why cybersecurity in IIoT isn’t optional—it must be structured, proactive, and lifecycle-driven.

The IEC 62443 standard requires organizations to “assess and address cybersecurity risk” across systems and assets. But in practice, many OT teams still rely on informal checklists or isolated controls.

This is where TARA (Threat Analysis and Risk Assessment) comes in.

TARA gives you a repeatable, risk-based approach to spot vulnerabilities, prioritize what matters, and link real threats to real-world controls. It moves you beyond guesswork and toward a system that can defend itself—before attackers reach your shop floor.

Just like the automotive world uses structured cybersecurity (ISO/SAE 21434) to protect people on the move, the IIoT world needs the same discipline to keep factories in motion.

Now Let’s Look at IEC 62443

To apply cybersecurity effectively across industrial systems, we need a common framework. That’s exactly what IEC 62443 provides: a set of international standards built specifically for Industrial Automation and Control Systems (IACS).

It helps answer key questions like:

• What needs to be protected?
• What kinds of attacks are we defending against?
• How strong should the security be?
• Who’s responsible for what?

The standard is designed to cover four key layers of responsibility, ensuring that cybersecurity is addressed at every level—from organizational policy to system design to individual components:

• Part 1: General Concepts – Definitions, models, and terminology
• Part 2: Policies & Procedures – For asset owners and governance
• Part 3: System-Level Requirements – For integrators and risk assessors
• Part 4: Component-Level Requirements – For device and software suppliers

By aligning your cybersecurity approach with IEC 62443, and using TARA as your core method for assessing and addressing risks, you can ensure that each layer of your industrial environment is defended—intelligently and systematically.

Whether you’re an asset owner, system integrator, or component manufacturer, IEC 62443 gives you clear guidance on how to build and maintain secure, resilient systems.

And when combined with TARA, it becomes a powerful way to move from compliance to confidence.

Who Uses IEC 62443 – and How

Stakeholder

Relevant Parts of IEC 62443

Asset Owners

Part 1, Part 2 (Policies & Governance)

System Integrators

Part 1, Part 3 (System Requirements)

Component Manufacturers

Part 1, Part 4 (Component Requirements)

Assessors & Auditors

All Parts

What Are Security Levels (SLs)?

In IEC 62443, Security Levels (SL 0–4) are used to define how much protection a system or component needs against intentional cyber threats. The higher the level, the more robust the security.

Security Levels (SL 0–4): Matching Protections to Threats

SL

Attacker Type

Protection Goal

SL 0

No protection

None

SL 1

Casual or accidental

Prevent inadvertent misuse

SL 2

Low-skill, intentional

Prevent simple, intentional misuse

SL 3

Skilled attacker

Defend against targeted attacks

SL 4

State-sponsored / APT

Defend against advanced persistent threats

SL vs. CAL: Comparing with Automotive

While IEC 62443 and ISO/SAE 21434 serve different domains, they reflect a shared truth: cybersecurity isn’t just about controls—it’s about confidence.

Just as TARA helps both industries align risk with appropriate safeguards, these standards offer complementary ways to scale protection based on risk—one through technical strength (SL), the other through assurance rigor (CAL).

Aspect

IEC 62443 – Security Level (SL)

ISO/SAE 21434 – Cybersecurity Assurance Level (CAL)

Domain

IIoT / Operational Technology (OT)

Automotive Embedded Systems

Emphasis

Technical protection strength

Security-by-design assurance

Purpose

Resist attacker capabilities

Guide depth of development & validation

Levels

SL 0 – SL 4

CAL 1 – CAL 4

Example

Firewalls, MFA, encrypted comms

TARA

SLs define what security protections are implemented.

CALs define how well those protections were developed, tested, and managed.

So, if SLs help you build hardened systems, CALs help you build trustworthy systems.

Both are essential—especially as automotive and industrial domains continue to converge in smart mobility, connected fleets, and automated manufacturing. A modern TARA must be fluent in both.

How to Use SLs in Practice

IEC 62443 helps you:

1. Assess the risk (via TARA or zone/conduit analysis)
2. Assign a Security Level to each zone/conduit based on:
   
   • Impact of a compromise
   • Feasibility of an attack
   • Exposure (external, internal, remote, physical)
3. Select controls that meet the minimum requirements of that SL

Practical TARA Workflow for Industrial IoT -How Block Harbor Performs IEC 62443-Aligned TARA

Now that we’ve seen how IEC 62443 SLs compare with ISO/SAE 21434 CALs, the next step is making these concepts real. So how can we perform TARA in a way that directly supports IEC 62443?

At Block Harbor, we don’t just hand you a checklist—we walk your team through the full cybersecurity lifecycle using tooling, coaching, and system thinking. Let’s walk through a practical, structured workflow to assess risk, assign SLs, and select controls tailored to industrial environments.

1. Draw the Zone-and-Conduit Map

We begin by building a Zone-and-Conduit Diagram collaboratively with your OT and IT leads. This gives us:

• Clear visibility into trust boundaries
• A shared map to align SL assignments
• The foundation for layered security design

We use a guided workshop or your system diagrams to get this done in hours—not weeks.

• Zones: Logical/physical areas like:
  
  
  
  • Zone 1: PLCs, Robots (Control Layer)
  • Zone 2: SCADA, HMIs (Supervisory Layer)
  • Zone 3: MES, Historian (Operations Layer)
  • Zone 4: Cloud, VPN, Remote Maintenance (External Layer)
  • Conduits: Interfaces between zones — wired/wireless networks, vendor tunnels, cloud links.

2. List Assets & Data Flows

Within each zone, we identify:

• Assets: PLCs, SCADA servers, HMIs, sensors, RTUs, switches, firewalls
• Data Flows: Commands, sensor readings, operational logs, firmware updates, historian data

Our template helps capture not just assets—but how they communicate, we ensure everything is linked to a zone, owner, and purpose—so downstream risk decisions make sense.

3. Brainstorm Threat Scenarios (STRIDE + ICS)

We facilitate threat modeling sessions using a curated STRIDE + ICS threat library. You won’t start from scratch.

✔️ You’ll get:

• ICS-specific threat examples (e.g., spoofed Modbus values, tampered ladder logic)
• Editable TARA templates
• Traceability to SL assignment logic

4. Feasibility Scoring – Guided by IEC 62443

Our worksheet includes dropdowns to rate:

Factor

Example

Elapsed Time

Time to breach: minutes, hours, or days

Expertise

Needed skills: general IT vs. ICS-specific

Window of Opportunity

Does the attack need timing (e.g., shift hours)?

Equipment

Tools: Laptop vs. JTAG interface, protocol fuzzers

Motivation

Is attacker casual, insider, or state-sponsored?

This helps your team quantify feasibility quickly and repeatably.

5. Score Impact

We evaluate consequences of each attack using these dimensions - You’ll get impact scores that support SL justification and align with compliance narratives.

Impact Area

Description

Safety

Could it harm workers, operators, or the public?

Environmental

Could it cause spills, emissions, or long-term ecological harm?

Financial

How much revenue would be lost? (e.g., downtime, rework, damage)

Reputational

Would this breach erode customer trust or brand equity?

Compliance/Legal

Does this violate standards (IEC 62443, NIST 800-82) or trigger legal penalties?

6. Risk Rating → SL Targeting → Control Selection

We calculate Risk = Feasibility × Impact to prioritize threats. Based on that:

• We help assign target SLs for each zone/conduit
• Pull from our control library to recommend SL 1–4 level protections
• Flag over- or under-secured zones (cost/benefit tradeoff)

Apply IEC 62443 Security Level (SL)-based Controls:

SL Level

Control Focus

SL 1

Basic protections: passwords, logging

SL 2

Role-based access, minimal segmentation

SL 3

Strong auth, encryption, anomaly detection

SL 4

Full isolation, secure boot, MFA, protocol hardening

7. Residual Risk Tracking – Built into Our Dashboards

After recommending mitigations:

• We help you track what’s still exposed
• Residual risk is tagged and versioned (e.g., new vendor integration)
• Can be exported for audit reports or customer inquiries

What Makes This BH-Grade?

• No theory-only output: we map risk to controls directly
• Co-designed with your team, not dumped on you
• Aligned to real deliverables: CSMS docs, procurement specs, audit readiness

Golden Rule : If it can stop production or hurt someone, TARA it.

Ready to Get Started?

We make it easy. You’ll get a complete TARA starter kit with step-by-step worksheets, an industrial threat library, and scoring guidance. Our hands-on workshops use your real systems—so your team gains practical experience, not just theory. All risks, controls, and residuals are tracked in a single dashboard for clear visibility. Plus, we support you long-term with audits, customer questionnaires, and incident reviews. Contact us today to streamline your IEC 62443-aligned TARA process and strengthen your industrial cybersecurity program.

‍