Security Glossary
Clear definitions for the terms you encounter in security audits, NIS2 assessments and embedded projects. Click any term to jump to it.A
Protecting programming interfaces against unauthorised access, data exfiltration and tampering. Encompasses authentication, authorisation, rate limiting and input validation. A core component of every backend security audit. Application Security Verification Standard — OWASP standard defining verifiable security requirements for web applications. Level 2 is the minimum for production backends, Level 3 for regulated environments such as healthcare or finance. B
Federal Office for Information Security (Germany). Publisher of relevant IT security standards (IT-Grundschutz, BSI C5) and the central authority for cybersecurity in Germany. C
Controller Area Network — serial bus system ubiquitous in vehicles and industrial controllers. Because the base protocol lacks authentication, it is a frequent attack surface in automotive and OT security. Configuring and securing cloud services (Azure, AWS, GCP) against known attack vectors. Includes IAM policies, network segmentation, encryption and monitoring — tailored to the deployment topology, not one-size-fits-all. Cyber Resilience Act — EU regulation effective September 2026. Requires 24-hour reporting for actively exploited vulnerabilities, SBOM and PSIRT process. Applies to all products with digital elements placed on the EU market. Common Vulnerability Scoring System — standardised severity scale (0–10) for security vulnerabilities. Enables objective prioritisation of findings in audit reports. D
Factory-set access credentials that have never been changed. The most common finding in embedded and IoT audits — every device with a default password is an open door. General Data Protection Regulation — EU framework for protecting personal data. Relevant in the security context for data processing in backends and IoT systems. F
Security review of the software running directly on an embedded device. Analyses boot chain, OTA updates, communication protocols and hardware interfaces. Methodologically aligned with IEC 62443-4-1. H
Systematic securing of a system against known attack vectors — from OS configuration and network rules to encrypted communication. Not a one-off task but an ongoing process. I
Identity and Access Management — managing identities and access rights. Overpermissive IAM policies are one of the most common backend security issues: too many privileges, no least-privilege, no rotation. International standard series for IT security in automation systems. Part 4-1 defines the secure development process, Part 4-2 defines component requirements (Security Levels 1–4). Core definition for OT and embedded security. Security of connected devices — from sensors and controllers to edge computers. Encompasses secure communication, access control, update mechanisms and hardware protection. Particularly relevant for OT environments under NIS2. International standard for information security management systems (ISMS). Defines requirements for establishing, implementing and maintaining a comprehensive security management framework. J
JSON Web Token — compact, URL-safe token format for transmitting claims. Security-relevant: misconfiguration (missing validation, weak algorithms, stale secrets) is one of the most common API vulnerabilities. N
EU directive on network and information security (2022/2555). Obliges operators of essential and important entities to demonstrable vulnerability assessment, incident response and supply-chain security. German transposition via NIS2UmsuCG. O
Over-the-Air update — wireless delivery of firmware updates to embedded devices. Security-critical: without cryptographic signature verification, rollback protection and secure transport it is an open door for tampering. The ten most critical security risks for web applications, periodically updated by the OWASP Foundation. Foundation of every backend security audit — from Broken Access Control to Security Misconfiguration. P
Targeted, exploit-focused testing of a system for exploitable vulnerabilities. Unlike the broader security audit, the focus is on practical proof — «Can we actually break in?» Product Security Incident Response Team — internal team or process for handling security incidents affecting own products. Becomes mandatory under the CRA from September 2026. R
Restricting the number of requests per time window per client or endpoint. Prevents brute-force attacks, credential stuffing and API abuse. One of the simplest and most effective API protection measures. S
Software Bill of Materials — complete list of all components, libraries and versions used in a software product. Prerequisite for assessing vulnerabilities in dependencies. CRA-mandatory from September 2026. Verified boot process: the device checks at power-on via cryptographic signatures that the loading software is genuine and unaltered. Protects against tampered firmware and rollback to insecure versions. Structured, holistic review of a system for security vulnerabilities — spanning code review, architecture and configuration analysis, through to dynamic testing. Broader than a pentest, with focus on reproducibility and documentation. Managing user sessions via login timeouts, token rotation and secure storage. Vulnerabilities here (session fixation, missing invalidation on logout) are among the OWASP Top 10. Threat-modelling methodology: Spoofing, Tampering, Repudiation, Information Disclosure, Denial of Service, Elevation of Privilege. Systematic walkthrough of possible attack vectors — the starting point of every professional security audit. T
ARM hardware security architecture (Cortex-M/-A). Isolates secret keys, crypto operations and safety-critical state machines in a protected memory region from the rest of the application — a hardware-based trust boundary. Z
Security architecture principle: no element is trusted by default, whether internal or external. Every request is identity-verified, authorised and encrypted. Foundation of modern cloud and network security concepts.