Muhammad Usman

Muhammad UsmanSep 12, 2026

🔐 IEC 62443-3-3: Understanding System Security Requirements & Security Levels In this video, I explain the fundamentals of IEC 62443-3-3 and how it helps organizations secure Industrial Automation and Control Systems (IACS). Key topics covered: • The 7 Foundational Requirements (FR1–FR7) • System Requirements (SRs) and Requirement Enhancements (REs) • Security Levels (SL1–SL4) • Target Security Level (SL-T) vs. Achieved Security Level (SL-A) • Zones and Conduits • How to apply IEC 62443-3-3 to real-world OT and robotic systems IEC 62443 is not just about implementing individual security controls—it provides a structured, risk-based approach to protecting industrial systems. 🎥 Watch the video and share your thoughts: Which IEC 62443 requirement do you find most challenging to implement in OT environments? #IEC62443 #OTSecurity #IndustrialCybersecurity #Cybersecurity #ICS #IACS #Robotics #CyberResilience #OT

Muhammad UsmanSep 15, 2026

🔐 SBOM + CRA: What does compliance actually mean for SMEs? The Cyber Resilience Act (CRA) is putting much more focus on understanding what is actually inside a digital product. One important requirement is maintaining information about the software components that make up the product — commonly addressed through a Software Bill of Materials (SBOM). But for many SMEs, the challenge isn't generating an SBOM. The real challenge is keeping it accurate, maintaining it throughout the product lifecycle, and using it for vulnerability management. So, how can an SME approach this? ✅ 1. Establish SBOM ownership Define who is responsible for creating, maintaining, reviewing, and approving the SBOM. ✅ 2. Automate SBOM generation Integrate SBOM generation into the software build/CI-CD process rather than creating it manually before a release. ✅ 3. Use a recognised format Formats such as CycloneDX or SPDX can provide machine-readable component information. ✅ 4. Include all relevant dependencies Don't focus only on the application's direct dependencies. Transitive dependencies, libraries, operating-system packages and other relevant software components may also need to be considered. ✅ 5. Connect SBOM with vulnerability management An SBOM becomes much more valuable when it can answer: “Where are we using this vulnerable component?” This enables faster impact analysis when a new CVE is discovered. ✅ 6. Keep the SBOM lifecycle aligned with the product When software changes, the SBOM should change with it. Versioning and traceability are therefore critical. ✅ 7. Define how SBOM information is provided SMEs should establish a controlled process for providing the required software-component information to customers and other relevant parties while protecting sensitive information. For industrial and robotics products, this becomes even more important because the software stack can include: Application → Middleware → Open Source → Libraries → OS → Drivers → Firmware The key mindset shift is: An SBOM should not be a compliance document created once. It should be a living software asset that supports vulnerability management throughout the product lifecycle. For SMEs, the goal isn't to build an unnecessarily complex SBOM program. It's to build a repeatable, automated and maintainable process that integrates SBOM generation with secure software development and vulnerability management. How is your organization managing SBOMs today — manually, through CI/CD automation, or through a dedicated SBOM management platform? #CyberResilienceAct #CRA #SBOM #SoftwareSecurity #Cybersecurity #ProductSecurity #OTSecurity #IEC62443 #VulnerabilityManagement #OpenSourceSecurity #IndustrialCybersecurity

Muhammad UsmanSep 11, 2026

Excellent perspective. I would add that in OT and industrial environments, Zero Trust becomes even more challenging because we cannot assume that every device can continuously authenticate or support modern security mechanisms. For example, a robot, PLC or safety controller may need to communicate with other components with strict latency and availability requirements. Therefore, Zero Trust in OT is not simply about “authenticate every request”; it also requires identity, least privilege, segmentation, integrity, continuous monitoring and risk-based access controls, while respecting safety and operational constraints. Ultimately, the objective is not to “trust nothing,” but to make trust explicit, verify it, limit it, and continuously validate it.