13. Verification, Safety and Cybersecurity

Introduction and Context

Microprocessors and microcontrollers increasingly control systems whose failure can injure people, damage equipment, interrupt essential services, or expose sensitive information. An embedded controller in a motor drive, medical instrument, vehicle, industrial robot, or smart meter must therefore do more than execute its nominal program. It must be shown to behave correctly, remain acceptably safe under faults, resist unauthorized manipulation, and recover predictably when software or hardware is updated.

Verification, functional safety, and cybersecurity are related but distinct disciplines. Verification asks whether an implementation satisfies specified requirements. Validation asks whether the resulting system is suitable for its intended use. Functional safety addresses hazards arising from malfunctioning behaviour. Cybersecurity protects confidentiality, integrity, availability, authenticity, and accountability against intentional or accidental threats. A secure controller may still be functionally unsafe, and a functionally safe controller may be vulnerable to malicious reprogramming. Sound engineering treats these properties together throughout the system life cycle.

For postgraduate engineers, the important shift is from testing the finished firmware to constructing an evidence-based assurance process. Requirements, architecture, source code, hardware, tools, test results, safety analyses, cryptographic keys, and update records must form a traceable chain. This chapter develops that chain and examines practical methods ranging from unit testing to hardware-in-the-loop simulation, secure boot, access control, and field updates.

Learning Objectives

After studying this chapter, the reader should be able to:

1. Distinguish verification, validation, functional safety, and cybersecurity assurance.

2. Develop a layered test strategy involving unit, integration, system, and hardware-in-the-loop testing.

3. Explain fault analysis using FMEA, FTA, and safety mechanisms such as watchdogs and redundancy.

4. Design the principal elements of a secure boot and authenticated firmware-update process.

5. Select suitable access-control, cryptographic, and key-management mechanisms for embedded systems.

6. Interpret the relevance of standards such as IEC 61508, ISO 26262, IEC 62443, ISO/SAE 21434, and Common Criteria.

7. Evaluate trade-offs among assurance, performance, cost, maintainability, and residual risk.

Assurance as a System Life-Cycle Activity

A useful assurance model contains four connected questions. First, what must the controller do? This is the requirements question. Second, how can the design fail or be attacked? This is the hazard and threat-analysis question. Third, how will the implementation be examined? This is the verification question. Finally, what evidence demonstrates that residual risk is acceptable? This is the validation and governance question.

Requirements should be written so that they are testable. “The motor shall be controlled safely” is inadequate; “when overspeed exceeds the specified threshold, torque command shall be inhibited within the defined response time” is verifiable. Safety requirements and security requirements should be linked to system functions, interfaces, assumptions, and acceptance criteria. A requirements traceability matrix can connect each requirement to design elements, source modules, test cases, test results, and defect records.

Verification is commonly divided into several levels:

• Unit verification examines an isolated function, module, driver, or class.
• Integration verification examines interactions among modules, peripherals, operating-system services, and communication stacks.
• System verification evaluates the complete controller against functional and non-functional requirements.
• Validation evaluates whether the system solves the intended operational problem in its real or representative environment.

Testing cannot prove the absence of every defect. It samples behaviour under selected conditions. Consequently, testing is complemented by reviews, static analysis, formal reasoning for critical properties, fault injection, code coverage, configuration control, and independent assessment.

A Layered Verification Strategy

Unit Testing and Structural Analysis

Unit tests isolate a small software element and control its inputs, outputs, timing assumptions, and dependencies. For microcontroller software, dependencies include memory-mapped registers, interrupt sources, timers, DMA engines, ADC values, and communication peripherals. Hardware abstraction layers and dependency injection make these elements replaceable by test doubles, allowing logic to be tested on a host computer before target hardware is available.

A strong unit test set includes normal cases, boundary values, invalid inputs, state transitions, timeout conditions, arithmetic overflow, loss of communication, and resource exhaustion. For example, a battery-monitoring function should be tested at the exact undervoltage threshold, immediately below and above it, during sensor disconnection, and when measurements arrive out of sequence.

Structural coverage measures which implementation elements have been exercised. Statement coverage shows executed statements; branch coverage examines decision outcomes; condition coverage examines Boolean subexpressions; and modified condition/decision coverage (MC/DC) seeks evidence that each condition can independently affect a decision. Coverage is not equivalent to correctness: executing every branch does not demonstrate that the requirements are complete or correct. Nevertheless, inadequate coverage often reveals untested assumptions.

Static analysis detects defects without executing the program. Typical findings include uninitialized variables, unreachable code, integer conversion errors, buffer overflows, race conditions, excessive stack use, and violations of a coding standard. Standards such as MISRA C and MISRA C++ are widely used to reduce language-related risks in safety- and security-sensitive embedded software. Their rules require engineering judgement; deviations should be documented, justified, and reviewed rather than silently ignored.

Integration Testing

Integration testing exposes faults that unit tests cannot see. A driver may be correct in isolation but fail when an interrupt changes a shared buffer while a protocol task reads it. A DMA transfer may overwrite memory reserved for another task. Two modules may interpret byte order, scaling, or timing differently. Integration tests therefore examine interfaces, scheduling, data ownership, initialization order, error propagation, and recovery behaviour.

Incremental integration is generally preferable to connecting every component at once. Drivers, middleware, application logic, and communication services can be integrated in controlled stages. Interface contracts should specify data format, timing, range, error codes, concurrency assumptions, and reset behaviour. Fault injection—such as corrupting a frame, delaying a response, forcing a sensor value, or interrupting power—makes integration testing more realistic.

System and Environmental Testing

System tests execute the complete product under representative loads and environmental conditions. They include functional tests, timing and throughput tests, memory and power tests, electromagnetic compatibility tests, thermal tests, reset and brownout tests, and endurance tests. A controller that passes a functional test at room temperature may fail when oscillator frequency, sensor characteristics, flash timing, or communication noise changes with temperature.

Test environments must be calibrated and configured. The firmware image, compiler version, linker script, bootloader, hardware revision, test instruments, and parameter files should be recorded. Reproducibility is especially important when a failure appears only after thousands of resets or a particular sequence of network traffic.

Hardware-in-the-Loop Testing

Hardware-in-the-loop (HIL) testing connects the real controller to a real-time simulator representing the plant. The controller generates actuator commands, while the simulator calculates plant response and returns sensor signals. A motor controller may be connected to a real-time electrical-machine model; an automotive control unit may receive simulated vehicle speed, wheel slip, and engine signals.

HIL testing occupies a valuable position between software simulation and physical testing. It permits repeatable, accelerated, and dangerous scenarios—such as overspeed, short circuit, sensor disagreement, or communication loss—without destroying equipment or endangering personnel. Its validity depends on model fidelity, simulator timing, I/O latency, signal conditioning, and correct correspondence between model assumptions and the physical system. HIL is not a substitute for final environmental and field validation, because it may omit mechanical tolerances, electromagnetic effects, installation errors, and human interaction.

A mature verification pipeline may automate compilation, static analysis, unit testing, target flashing, HIL execution, log collection, coverage reporting, and release approval. Automation improves repeatability, but it does not remove the need to review test adequacy and interpret anomalous results.

Safety Engineering for Embedded Controllers

Functional safety concerns unreasonable risk caused by hazards resulting from malfunctioning behaviour. The analysis begins with intended functionality and operating conditions, then identifies hazardous events, estimates risk, and specifies safety measures. IEC 61508 provides a generic framework for electrical, electronic, and programmable electronic safety-related systems. Sector-specific adaptations include ISO 26262 for road vehicles, IEC 62304 for medical-device software, and IEC 61511 for process industries.

The safety life cycle normally includes hazard analysis, allocation of safety requirements, architecture, implementation, verification, validation, operation, maintenance, and modification control. Safety integrity levels (SILs) in IEC 61508 and automotive safety integrity levels (ASILs) in ISO 26262 express required risk reduction using sector-specific methods. They are not simple labels of product quality and should not be assigned without the relevant analysis.

FMEA and Fault-Tree Analysis

Failure Modes and Effects Analysis (FMEA) proceeds from component or function failure modes toward their effects. For a temperature sensor, failure modes may include open circuit, short circuit, frozen value, incorrect calibration, or intermittent connection. The analysis identifies local effects, system effects, detection mechanisms, and required reactions. A design FMEA focuses on architecture; a process FMEA focuses on manufacturing and assembly risks.

Fault-tree analysis (FTA) proceeds in the opposite direction. Starting with a top event such as “uncontrolled actuator motion,” it decomposes combinations of failures using logical AND and OR relationships. FTA is useful for showing whether independent protective barriers are genuinely independent. Common-cause failures—such as one power supply, clock, software defect, or environmental event affecting redundant channels—must be considered explicitly.

Safety Mechanisms

Typical embedded safety mechanisms include watchdog timers, lockstep processors, memory error-correcting codes, range and plausibility checks, redundant sensors, end-to-end communication protection, safe-state outputs, clock monitoring, brownout detection, periodic task supervision, and independent shutdown paths. A watchdog is effective only when its servicing depends on evidence that critical tasks have completed correctly; blindly refreshing it in a central loop can conceal failures.

A safe state is application-dependent. For a heater it may mean removing power; for a medical infusion pump it may require controlled continuation or an alarm rather than abrupt shutdown; for a flight-control system, degradation may be safer than total disengagement. Safety mechanisms must therefore be tied to hazard analysis and verified for response time, diagnostic coverage, and failure behaviour.

Embedded Cybersecurity Architecture

Cybersecurity begins with a threat model rather than with a particular cryptographic algorithm. Assets may include firmware, calibration data, cryptographic keys, personal information, safety parameters, and availability of control functions. Threat sources may be remote attackers, malicious insiders, compromised maintenance tools, counterfeit components, or accidental misuse. Attack surfaces include debug ports, bootloaders, wireless interfaces, field buses, update mechanisms, diagnostic protocols, external memory, and supply-chain tools.

Threat analysis considers spoofing, tampering, repudiation, information disclosure, denial of service, and elevation of privilege. The result should identify security objectives, trust boundaries, attack assumptions, and compensating controls. Security risk is dynamic: a previously acceptable design may become vulnerable when a new communication interface is added or a cryptographic algorithm is weakened by advances in computation.

Root of Trust and Secure Boot

Secure boot establishes a chain of trust from an immutable or protected root to the executing application. A device begins with trusted boot code, verifies the next boot stage, and ultimately verifies the application image and essential configuration. Verification normally uses a digital signature: the producer signs a hash of the image with a private key, and the device checks the signature using an authenticated public key.

The boot process should also verify image version, device compatibility, memory location, and security policy. Anti-rollback protection prevents installation of an older but vulnerable image, usually by storing a monotonic version counter or one-way security state. If verification fails, the controller must enter a defined recovery mode rather than execute untrusted code. Recovery itself must be protected; otherwise an attacker can replace the recovery image or exploit an unauthenticated service interface.

Encryption and authentication serve different purposes. Digital signatures provide authenticity and integrity of an image. Encryption provides confidentiality, which may be required to protect intellectual property or sensitive configuration. An encrypted but unsigned image can still be replaced by an attacker. In many systems, authenticated encryption such as AES-GCM or ChaCha20-Poly1305 protects data in transit, while asymmetric signatures authenticate firmware and establish trust.

Key Management

The strength of an algorithm cannot compensate for poor key management. Device keys should be generated or provisioned through controlled processes, stored in protected hardware where feasible, and associated with device identity and lifecycle status. Private production keys require stringent separation of duties, restricted access, backup policy, rotation, revocation, and audit logging. Test keys must never be accepted in production.

A hardware security module, secure element, or trusted execution environment can protect keys and perform cryptographic operations. However, such components introduce cost, software dependencies, and integration obligations. Engineers must define what happens if a device is repaired, transferred to a new owner, decommissioned, or found to be compromised.

Access Control and Debug Security

Access control should follow least privilege: each user, task, service, or diagnostic function receives only the permissions required for its role. Authentication identifies an entity; authorization determines what it may do; auditing records relevant actions. Role-based access control is useful for maintenance personnel, operators, and administrators, while capability-based designs can restrict individual software components.

Debug interfaces such as JTAG and SWD are valuable during development but are powerful attack paths in deployed products. Production devices should disable, lock, or authenticate debug access, while preserving a controlled recovery process. Credentials should not be embedded as universal passwords. Rate limiting, secure logging, challenge-response authentication, and physical-presence requirements may be appropriate for service operations.

Secure Firmware Updates

A secure update mechanism must authenticate the image, protect update transport where necessary, validate compatibility, preserve power-failure recovery, and provide an auditable result. A robust sequence is:

1. Obtain the image through an authenticated channel.

2. Verify signature, image type, version, target identity, and integrity.

3. Store the image in an isolated or inactive partition.

4. Install or activate it atomically.

5. Confirm successful boot and health checks.

6. Commit the update only after confirmation; otherwise roll back safely.

Dual-bank or A/B flash layouts support rollback after an interrupted update, but rollback must not reintroduce a vulnerable version. Updates may also alter safety functions, calibration, or regulatory behaviour. Consequently, release approval should include regression tests, cybersecurity review, safety-impact analysis, configuration identification, and field-monitoring plans.

Standards, Governance, and Evidence

Standards provide processes and expectations, not automatic compliance. IEC 61508 emphasizes safety life-cycle management and systematic and random hardware failures. ISO 26262 addresses automotive hazard analysis, ASIL-oriented development, hardware metrics, software practices, and production operation. IEC 62443 addresses industrial automation and control-system security across components, systems, and organizations. ISO/SAE 21434 focuses on cybersecurity engineering for road vehicles. NIST guidance and secure-development frameworks provide broadly applicable practices, while Common Criteria evaluates security functionality against defined protection profiles.

Compliance requires objective evidence: approved requirements, review records, analysis results, test procedures, tool qualifications where relevant, defect disposition, configuration baselines, supplier evidence, and change-impact assessments. Independence of review should increase with risk. Governance also includes vulnerability disclosure, incident response, patch support, asset inventory, end-of-life planning, and retention of security logs.

There is a strategic tension between rapid product release and assurance depth. Excessively rigid processes can encourage workarounds; inadequate discipline creates hidden technical and security debt. Risk-based planning is therefore essential. High-risk functions deserve stronger independence, fault injection, formal analysis, and longer regression campaigns than non-critical user-interface features.

Illustrative Case Study: Secure and Safe Industrial Pump Controller

Background

Consider an illustrative industrial pump controller based on a microcontroller with an analog pressure sensor, variable-speed drive interface, Ethernet diagnostics, a bootloader, and a watchdog. The controller regulates pressure in a chemical process. A loss of control can cause equipment damage, while unauthorized firmware could alter pump speed or disable alarms.

Situation and Problem

An initial prototype passes nominal functional tests. However, the design uses an unprotected bootloader, leaves the debug connector active, refreshes the watchdog from a low-priority service task, and accepts sensor values without plausibility checks. Firmware updates are performed using a memory card. Management wants remote maintenance without compromising plant safety.

Analysis

FMEA identifies open-circuit and frozen-value sensor failures. FTA shows that loss of pressure control can result from sensor failure combined with inadequate diagnostics or from corrupted control software. Threat analysis identifies malicious update images, stolen maintenance credentials, exposed Ethernet services, and physical access to the debug port. The safety and cybersecurity analyses overlap at the firmware and communication boundaries but retain different acceptance criteria.

Approach and Solution

The engineering team defines a safety requirement that implausible or contradictory pressure measurements shall cause a bounded-speed mode and alarm within the required response time. Two plausibility tests compare pressure rate of change and an independent process limit. A hardware watchdog is serviced only after a supervisory task confirms completion of control, communication, and diagnostic tasks. A separate shutdown path limits the drive when the controller fails to meet timing requirements.

The boot ROM verifies a signed bootloader, and the bootloader verifies a signed application using a public key anchored in protected memory. Image versions are monotonic. An A/B update layout permits recovery after power interruption. Ethernet diagnostics require authenticated sessions and expose only role-appropriate commands. The debug port is locked in production. Keys are provisioned individually, and maintenance actions are logged.

Testing proceeds from unit tests for limit and timeout logic, through integration tests involving sensor and drive interfaces, to HIL tests for sensor freezing, rapid pressure changes, communication flooding, interrupted updates, and repeated resets. Static analysis and code review examine arithmetic, concurrency, memory boundaries, and cryptographic API use. A traceability matrix links hazards and threats to requirements and tests.

Outcome

The revised controller has a defined degraded mode, rejects unauthorized images, recovers from interrupted updates, and produces evidence suitable for an independent assessment. Remote maintenance remains available, but it is constrained by authentication, authorization, logging, and safety interlocks. The case demonstrates that cybersecurity controls must not accidentally interfere with a safety response; for example, an alarm or emergency shutdown cannot depend on a remote server being reachable.

Learning Points

The principal lesson is architectural. Security added at the network boundary cannot compensate for an untrusted boot chain, and a watchdog alone cannot establish safety. Hazard analysis, threat modeling, verification planning, and operational governance must influence the design from its earliest stages.

Challenges, Limitations, and Common Errors

Several errors recur in embedded assurance projects. Testing only nominal behaviour leaves boundary, timing, reset, and fault cases unexplored. Measuring code coverage without examining requirements creates false confidence. Treating a development board as equivalent to the production hardware overlooks clock, memory, power, EMC, and manufacturing differences. Using a single shared key across all devices makes compromise widespread and prevents meaningful revocation.

Other common mistakes include relying on obscurity instead of authentication, encrypting firmware without signing it, leaving maintenance ports permanently enabled, storing credentials in source code, permitting unrestricted rollback, and failing to test update interruption. Safety mechanisms can also create new hazards if they produce an abrupt actuator transition or if redundant channels share the same defective software, power source, or data.

Cryptography has operational limitations. Algorithms require correct nonce management, secure randomness, protected keys, and careful implementation. Security controls consume memory, processing time, energy, and maintenance capacity. Certification evidence can become obsolete after a compiler, library, hardware revision, or threat environment changes. These limitations should be recorded as residual risks and managed through monitoring and change control.

Professional and Ethical Responsibilities

Engineers have a duty to disclose safety defects and significant vulnerabilities through appropriate organizational channels and, when necessary, regulators or affected customers. Concealing a known weakness because a release date is inconvenient violates professional responsibility. Privacy must be considered when diagnostic logs contain operator identity, location, production data, or personal information. Access to such logs should be limited and retention should be justified.

Supply-chain governance is equally important. Third-party libraries, compilers, protocol stacks, and silicon components introduce dependencies that require vulnerability monitoring and version control. A software bill of materials supports incident response, although it is not by itself a security control. Organizations should define who can approve emergency patches, how safety impact is assessed, and how customers are informed when a vulnerability affects deployed equipment.

Current Developments and Best Practices

Modern microcontrollers increasingly provide hardware roots of trust, secure elements, memory protection, trusted execution environments, measured boot, cryptographic accelerators, and lifecycle states that distinguish development, manufacturing, service, and production. Remote attestation can allow a verifier to assess device software state, but it raises privacy, availability, and trust-governance questions. Continuous vulnerability monitoring and over-the-air update infrastructure are becoming normal for connected products.

Artificial intelligence can assist static-analysis prioritization, anomaly detection, log correlation, and test-case generation. It should be treated as an engineering aid rather than as an authority: generated tests may miss requirements, and anomaly models can produce false alarms or be manipulated. Safety decisions require explainable evidence and human accountability.

Effective practice is characterized by a few durable principles: define testable requirements; integrate safety and threat analysis; minimize attack surface; establish a hardware-backed root of trust; use least privilege; protect and rotate keys; make updates authenticated and recoverable; test faults and abuse cases as well as nominal operation; automate repeatable evidence collection; maintain traceability; and reassess risk whenever hardware, software, interfaces, suppliers, or operating conditions change.

Chapter Summary

Verification demonstrates, through reviews, analysis, and testing, that an embedded controller satisfies its requirements; validation confirms suitability for intended operation. A layered strategy combines unit, integration, system, environmental, and HIL testing with static analysis, coverage assessment, fault injection, and traceability. Functional safety uses hazard analysis, FMEA, FTA, safety integrity concepts, diagnostic mechanisms, and defined safe states to reduce risk from malfunction. Cybersecurity uses threat modeling, a hardware or protected root of trust, secure boot, signatures, encryption where needed, least-privilege access, protected debug interfaces, individual keys, and authenticated, anti-rollback firmware updates. Standards guide life-cycle processes, but compliance depends on objective evidence and competent governance. The strategic goal is not merely a passing test result; it is a controller whose behaviour, security, maintenance, and residual risks remain understood throughout its operational life.

Key Terms

Verification: Evaluation of whether an implementation satisfies specified requirements.

Validation: Evaluation of whether a system is suitable for its intended use and environment.

Functional safety: Reduction of unacceptable risk caused by malfunctioning behaviour of a system.

Cybersecurity: Protection of systems, data, and services against unauthorized or harmful actions.

Traceability: Ability to relate requirements to design, implementation, tests, and evidence.

Unit testing: Testing an isolated software function or module.

Integration testing: Testing interactions among software, hardware, and interface components.

Hardware-in-the-loop: Testing a real controller against a real-time simulated plant.

FMEA: Failure analysis that begins with component or function failure modes and examines their effects.

Fault-tree analysis: Deductive analysis that decomposes a hazardous top event into contributing failures.

Watchdog timer: Independent timer that resets or places a controller in a defined state when servicing fails.

Safe state: Condition in which system behaviour presents an acceptably low hazard after a fault.

Root of trust: Protected initial authority used to establish authenticity of subsequent software or data.

Secure boot: Startup process that executes only authenticated and authorized firmware.

Digital signature: Cryptographic evidence of data origin and integrity created with a private key.

Anti-rollback: Protection preventing installation of an obsolete or vulnerable software version.

Least privilege: Restricting an entity’s permissions to only those necessary for its role.

Threat model: Structured description of assets, attackers, attack surfaces, assumptions, and controls.

Safety integrity level: A risk-reduction classification used in standards such as IEC 61508.

A/B update: Firmware-update design using two image areas to support activation and recovery.

Review Questions

Short Answer Questions

1. Distinguish verification from validation in an embedded-controller project.

2. What information should be included in a requirements traceability matrix?

3. Why is HIL testing valuable for safety-related controllers?

4. State two differences between digital signatures and encryption.

5. Why should a production debug interface be disabled or authenticated?

Long Answer Questions

1. Explain a complete layered verification strategy from unit testing to HIL testing, including the limitations of coverage metrics.

2. Describe how FMEA and fault-tree analysis can be applied to a microcontroller-based actuator system.

3. Explain the architecture and operation of a secure-boot chain, including anti-rollback protection.

4. Discuss key management, access control, and secure firmware updates as parts of embedded cybersecurity.

5. Compare the purposes of functional-safety and cybersecurity standards and explain why neither can replace the other.

Analytical / Application Questions

1. A controller passes all nominal tests but occasionally commands an actuator after a sensor cable is disconnected. Propose an investigation and verification plan using fault injection, integration testing, and safety analysis.

2. Design a secure update process for a field-deployed controller that may lose power during installation. Identify the trust anchors, image checks, storage arrangement, recovery behaviour, and post-update tests.

3. An industrial controller uses redundant sensors connected to a common power supply and identical software channels. Analyze the residual risks and recommend architectural changes to improve independence and cybersecurity.

22. Multiple Choice Questions with Answers

Question 1

Which activity most directly demonstrates that an implemented software module satisfies its specified input-output behaviour?

A. Unit testing

B. Threat modeling

C. Supply-chain auditing

D. Environmental qualification

Correct Answer: A. Unit testing

Question 2

A principal advantage of hardware-in-the-loop testing is that it allows engineers to

A. Eliminate the need for physical validation

B. Execute repeatable hazardous plant scenarios using a real controller

C. Prove that source code contains no defects

D. Avoid modelling plant dynamics

Correct Answer: B. Execute repeatable hazardous plant scenarios using a real controller

Question 3

Why is code coverage alone insufficient as evidence of correctness?

A. Coverage cannot measure whether requirements are complete or correct

B. Coverage can only be measured on hardware

C. Coverage is unrelated to executed statements

D. Coverage prevents integration testing

Correct Answer: A. Coverage cannot measure whether requirements are complete or correct

Question 4

In a secure-boot process, a digital signature primarily provides

A. Confidentiality of the firmware image

B. Higher processor clock frequency

C. Authenticity and integrity of the firmware image

D. Physical protection from overheating

Correct Answer: C. Authenticity and integrity of the firmware image

Question 5

Which control best prevents an attacker from installing an old firmware version containing a known vulnerability?

A. Image compression

B. Anti-rollback protection

C. A faster watchdog

D. Statement coverage

Correct Answer: B. Anti-rollback protection

Question 6

A watchdog provides stronger safety evidence when it is serviced

A. Unconditionally by any interrupt

B. Only after a supervisor confirms completion of critical tasks

C. Only during software compilation

D. By an external network server

Correct Answer: B. Only after a supervisor confirms completion of critical tasks

Question 7

Which statement correctly distinguishes authentication and authorization?

A. Authentication identifies an entity; authorization defines its permitted actions

B. Authentication encrypts data; authorization compresses it

C. Authentication disables debugging; authorization resets hardware

D. Authentication measures coverage; authorization measures latency

Correct Answer: A. Authentication identifies an entity; authorization defines its permitted actions

Question 8

In the pump-controller case, an A/B firmware layout primarily supports

A. Higher sensor resolution

B. Recovery from interrupted or unsuccessful updates

C. Removal of all cryptographic keys

D. Automatic elimination of common-cause failures

Correct Answer: B. Recovery from interrupted or unsuccessful updates

Question 9

Which situation represents a common-cause concern in redundant safety channels?

A. The channels use independent power supplies and diverse implementations

B. Both channels share identical software and one power supply

C. Each channel has separate sensors and monitoring

D. One channel is independently tested

Correct Answer: B. Both channels share identical software and one power supply

Question 10

Which practice most directly reduces the impact of a compromised maintenance account?

A. Using one universal password for all devices

B. Granting every account administrator privileges

C. Applying least privilege, authentication, and audit logging

D. Disabling all update records

Correct Answer: C. Applying least privilege, authentication, and audit logging