--- title: "The SECURE Method™ — IEC 62443 Simplified for Industrial Networks" description: "The SECURE Method is a six-step framework that makes IEC 62443 actually usable. Segment, Establish, Control, Update, Respond, Evaluate. Each step mapped to a section of IEC 62443. Originated by River Caudle." canonical: "https://rivercaudle.com/secure-method/" author: "River Caudle" keywords: - SECURE Method - IEC 62443 - IEC 62443 simplified - OT cybersecurity - industrial cybersecurity - ICS security - SCADA security - operational technology security - network segmentation - zones and conduits - security levels - SL-1 SL-2 SL-3 SL-4 - patch management OT - incident response OT - access control industrial - River Caudle - Riverman - industrial independence robots: index, follow schema_type: HowTo --- # The SECURE Method™ **IEC 62443 simplified for industrial networks.** A six-step framework that turns the IEC 62443 standard into a sequence an operator can actually follow without breaking production. Originated by [River Caudle](https://rivercaudle.com/) — OT/ICS practitioner. --- ## Why this exists Most industrial cybersecurity frameworks are written by people who have never had to keep a plant running. **The SECURE Method is not.** It is a six-step program — *Segment, Establish, Control, Update, Respond, Evaluate* — that takes the IEC 62443 standard and turns it into a sequence an operator can actually follow without breaking production. *Making industrial cybersecurity standards actually usable in the real world.* --- ## Overview — six steps, mapped to IEC 62443 | Step | Action | IEC 62443 Reference | |:----:|------------------------------|--------------------------------------------------| | **S** | Segment your networks | 62443-3-2 — Zones & Conduits | | **E** | Establish security levels | 62443-3-3 — Security Level Targets | | **C** | Control access | 62443 FR1 — Access Control | | **U** | Update responsibly | 62443-2-3 — Patch Management | | **R** | Respond to incidents | 62443-2-1 — Incident Response | | **E** | Evaluate continuously | 62443-2-1 — Cybersecurity Management System | --- ## S — Segment Your Networks **IEC 62443 reference:** Zones and Conduits *(IEC 62443-3-2)* ### What it means - Separate networks by risk and function - The IT/OT boundary is the minimum requirement - Isolate safety systems **always** - Document what can't be segmented and why ### Practical implementation - Create functional zones — *production, safety, maintenance* - Use VLANs and firewalls to enforce boundaries - Separate critical systems from convenience systems - Map data flows between zones and control them > *"If everything is on one network, one breach kills everything."* --- ## E — Establish Security Levels **IEC 62443 reference:** Security Level Targets *(IEC 62443-3-3)* ### What it means - **SL-1** — protection from accidents and human error - **SL-2** — protection from basic attacks and malware - **SL-3** — protection from sophisticated, targeted attacks - **SL-4** — protection from nation-state-level threats ### Reality check - Most facilities need SL-2 for production, SL-3 for safety systems - SL-4 is for nuclear plants and critical infrastructure - Don't over-engineer security that breaks operations - Start with SL-1 and build up based on actual threats > *"Match protection to actual risk, not imaginary threats."* --- ## C — Control Access **IEC 62443 reference:** Access Control *(IEC 62443 FR1)* ### What it means - **Physical security** — locks, badges, cameras where they matter - **Role-based access** — operator, engineer, admin with clear boundaries - **Emergency override** — when security can't prevent operations - **Regular audits** — who has access to what, and why ### Practical approach - Lock network cabinets like you lock control rooms - Use existing plant badge systems for network access - Create emergency procedures that bypass security safely - Audit permissions quarterly, not annually > *"The best access control is the one people actually follow."* --- ## U — Update Responsibly **IEC 62443 reference:** Patch Management *(IEC 62443-2-3)* ### What it means - **Risk-based schedule** — critical security patches fast, everything else planned - **Test before production** — use development systems or offline testing - **Document exceptions** — what can't be patched and why - **Compensating controls** — extra protection for unpatched systems ### Industrial reality - Some systems can't be patched during production - Test patches on non-critical systems first - Use network segmentation to protect unpatchable systems - Schedule updates during planned maintenance windows > *"Patch management that breaks production isn't security — it's sabotage."* --- ## R — Respond to Incidents **IEC 62443 reference:** Incident Response *(IEC 62443-2-1)* ### What it means - **Priority order** — safety > production > evidence preservation - **OT-specific procedures** — don't assume IT incident response works - **Defined response team** — operations leads, IT supports - **Practice scenarios** — tabletop exercises with real constraints ### Response framework 1. **Immediate** — stop the threat, maintain safe operations 2. **Short-term** — isolate affected systems, restore production 3. **Long-term** — investigate, improve defenses, document lessons 4. **Continuous** — update procedures based on what you learned > *"In OT, safety trumps everything — including perfect forensics."* --- ## E — Evaluate Continuously **IEC 62443 reference:** Cybersecurity Management System *(IEC 62443-2-1)* ### What it means - **Monthly health checks** — are your defenses still working? - **Quarterly assessments** — what changed, what's broken? - **Annual program review** — strategic evaluation and planning - **Continuous improvement** — fix what's broken, improve what works ### Evaluation cycle | Cadence | Activity | |------------|------------------------------------------------| | Daily | Monitor alerts and system health | | Weekly | Review security events and false positives | | Monthly | Check access permissions and system updates | | Quarterly | Assess threats and update procedures | | Annually | Strategic review and budget planning | > *"Security isn't a project — it's an ongoing operational requirement."* --- ## Implementation Roadmap Twelve months. Four phases. Built to be followed. ### Phase 1 — Foundation *(Months 1–3)* **Focus:** Segment & Establish - Complete network inventory and mapping - Implement basic IT/OT segmentation - Define security levels for each zone **Success metric:** *Clear network boundaries that people understand.* ### Phase 2 — Access Control *(Months 4–6)* **Focus:** Control & Update - Deploy role-based access controls - Establish patch management procedures - Lock down physical access points **Success metric:** *Only authorized people can access critical systems.* ### Phase 3 — Operations *(Months 7–9)* **Focus:** Respond & Evaluate - Create incident response procedures - Deploy monitoring and alerting - Conduct first tabletop exercise **Success metric:** *The team knows what to do when something goes wrong.* ### Phase 4 — Maturity *(Month 10+)* **Focus:** Continuous improvement - Regular security assessments - Advanced threat detection - Automated response capabilities **Success metric:** *Security that improves operations instead of hindering them.* --- ## SECURE vs. Traditional IT Security | Aspect | Traditional IT | SECURE Method | |-------------|-------------------------|-----------------------------------------| | Priority | Confidentiality first | **Availability first** | | Patching | Patch immediately | **Test, then patch during maintenance** | | Access | Role-based complexity | **Function-based simplicity** | | Monitoring | Log everything | **Monitor what matters to operations** | | Response | Preserve evidence | **Stop the threat, maintain safety** | | Compliance | Checkbox security | **Risk-based implementation** | OT is not late-model IT. It is a different discipline. The SECURE Method is built on that distinction. --- ## Common Implementation Mistakes ### What doesn't work - Copying IT security policies directly to OT - Implementing security that requires constant IT support - Choosing tools based on features instead of operational fit - Assuming all OT systems can be patched like IT systems ### What does work - Security policies written by operations, for operations - Simple, reliable security that plant personnel can maintain - Tools that integrate with existing operational procedures - Risk-based security that matches actual threats --- ## Success Metrics ### Technical metrics - **Segmentation** — clear network boundaries with documented exceptions - **Access control** — regular audits with prompt cleanup - **Patch management** — defined process with measurable compliance - **Incident response** — mean time to containment under 15 minutes ### Operational metrics - **Production impact** — security incidents causing zero unplanned downtime - **User adoption** — procedures followed without workarounds - **Cost effectiveness** — security investment showing measurable ROI - **Continuous improvement** — regular updates based on lessons learned --- ## Closing > *"The best industrial cybersecurity is the kind that makes operations more reliable, not less."* The SECURE Method is a sequence, a doctrine, and a refusal — a refusal to keep pretending that enterprise IT security policies will keep a plant running. Build it. Audit it. Ship it. Then evaluate it again. --- ## See also - **River Caudle's main site:** - **Industrial Independence Architecture:** - **Conversational Factory:** - **MarlinSpike / GrassMarlin successor:** --- *Document — The SECURE Method™ · Originator — R. Caudle · Standard — IEC 62443 · Rev. 01 · Issued Houston, Texas, 2026.05.11*