Systems Engineering, Testing and Product Lifecycle

Introduction

IoT and embedded products are socio-technical systems: they combine sensors, actuators, processors, communications, cloud services, applications, people, operational procedures, and regulatory constraints. Their behaviour emerges from interactions among these elements rather than from any single component. A temperature sensor may be accurate in isolation yet produce an unsafe system if its sampling schedule, time synchronisation, communication retry policy, and alarm logic are poorly integrated.

Systems engineering provides a disciplined method for transforming stakeholder needs into a verified and validated system. Testing supplies evidence that the implementation satisfies its requirements and remains dependable under realistic and abnormal conditions. Product-lifecycle management connects conception, development, deployment, operation, maintenance, evolution, retirement, and disposal.

For IoT products, lifecycle thinking is especially important because devices may remain deployed for a decade, operate in hostile environments, process personal data, and depend on remote infrastructure. Security vulnerabilities, battery degradation, cloud-service changes, and supply-chain discontinuities can make a technically successful prototype an operational failure.

Learning Objectives

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

1. Explain the role and principles of systems engineering in IoT and embedded development.
2. Convert stakeholder needs into traceable, testable system requirements.
3. Distinguish verification, validation, qualification, commissioning, and acceptance testing.
4. Design a risk-based test strategy covering hardware, firmware, networks, cloud services, and human operation.
5. Apply reliability, availability, maintainability, and failure-analysis concepts.
6. Analyse lifecycle decisions involving updates, configuration management, cybersecurity, sustainability, and product retirement.
7. Evaluate an integrated IoT case using technical, managerial, ethical, and regulatory criteria.

1. Systems Engineering as an Integrating Discipline

Systems engineering is an interdisciplinary approach for specifying, designing, integrating, assuring, operating, and retiring systems. It manages both the technical baseline and the relationships among stakeholders, components, interfaces, risks, and lifecycle activities.

A useful systems-engineering perspective treats an IoT solution as a hierarchy:

• Mission or business system: the overall service, such as cold-chain monitoring.
• Operational system: users, facilities, procedures, connectivity, and service providers.
• IoT system: devices, gateways, networks, platforms, applications, and data stores.
• Subsystems: sensing, power, processing, communication, security, actuation, and enclosure.
• Components: integrated circuits, batteries, antennas, sensors, software modules, and connectors.

The hierarchy is not merely organisational. A requirement at one level constrains design at lower levels. For example, a business requirement for continuous refrigeration monitoring may imply a device-level requirement for local data buffering during network outages and a service-level requirement for timely alarm escalation.

1.1 The systems-engineering technical process

A practical process includes:

1. Stakeholder identification and mission analysis: determine users, owners, maintainers, regulators, affected communities, and adversaries.
2. Needs and concept exploration: compare alternative operational concepts and define system boundaries.
3. Requirements analysis: express required capabilities, performance, interfaces, constraints, and assurance properties.
4. Architecture definition: allocate functions to hardware, firmware, communications, cloud services, and people.
5. Design synthesis: select technologies and create detailed implementations.
6. Implementation: manufacture hardware, develop software, configure infrastructure, and prepare procedures.
7. Integration: combine elements progressively and control interfaces.
8. Verification and validation: establish objective evidence of conformance and fitness for purpose.
9. Operation and maintenance: monitor performance, manage incidents, patch vulnerabilities, and control changes.
10. Retirement: migrate data, revoke credentials, recover assets, and dispose of equipment responsibly.

These activities are iterative. A prototype test may reveal that a requirement is infeasible, unsafe, or ambiguous. Requirements and architecture must then be revised under configuration control rather than informally changed.

1.2 Systems thinking and emergent properties

Important properties often emerge only after integration. Examples include end-to-end latency, resilience to intermittent connectivity, privacy, electromagnetic compatibility, safe failure, energy autonomy, and fleet-wide update safety. Component tests cannot fully establish these properties.

A systems engineer therefore asks:

• What happens when a dependency fails?
• Which component owns each decision?
• What is the safe state during loss of power or communication?
• How are time, identity, configuration, and data provenance maintained?
• Can the system be diagnosed without exposing sensitive information?
• Can it be updated without bricking devices or creating incompatible versions?

2. Requirements Engineering and Traceability

A requirement is a necessary, stated, and testable condition or capability. Good requirements are unambiguous, feasible, necessary, singular, consistent, traceable, and verifiable.

A useful requirement usually identifies an actor or system element, an action or property, and measurable conditions. “The device shall report temperature every 60 s ± 5 s when powered and connected” is stronger than “The device should report temperature regularly.” The former has an observable response and tolerance.

Requirements commonly include:

2.1 Quality attributes and trade-offs

Quality attributes are frequently competing. Increasing sampling frequency can improve detection but reduce battery life and increase network cost. Stronger cryptographic protection may increase computation, memory, and latency. Redundancy can improve availability but increase cost and maintenance complexity.

Trade-offs should be explicit. A weighted decision model can support preliminary comparison:

Here, S_j is the score of design alternative j, w_i is the normalised importance weight of criterion i, and r_ij is the normalised rating of alternative j on criterion i. The weights should satisfy ∑w_i = 1. This model is appropriate for transparent screening, not for hiding safety or legal constraints inside a numerical score. A design that violates a mandatory safety requirement must be rejected regardless of its total score.

2.2 Traceability

A requirements traceability matrix links each requirement to its source, architecture element, implementation, test procedure, result, defect record, and release. Bidirectional traceability is essential: every test should address a requirement or justified quality risk, and every requirement should have verification evidence.

Traceability supports impact analysis. If an encryption library changes, engineers can identify affected firmware modules, threat controls, tests, release notes, and deployed product versions. It also provides evidence for audits and regulated acceptance.

3. Architecture, Interfaces, and Lifecycle Models

An IoT architecture is commonly decomposed into device, edge or gateway, network, platform, application, and operational layers. The decomposition should be functional rather than tied to a fashionable reference model. Some products perform analytics on the device; others rely on edge nodes or cloud services.

Interfaces deserve special attention because many failures occur at boundaries. Interface control documents should define data formats, units, timing, error codes, authentication, version compatibility, ownership, and recovery behaviour. For example, a timestamp interface must define time zone, precision, clock source, handling of invalid time, and whether ordering is based on event time or arrival time.

3.1 Lifecycle models

A sequential model can be appropriate where requirements are stable, hardware interfaces are safety-critical, and formal reviews are mandatory. Iterative or agile development is valuable where user needs and software behaviour evolve. Hardware development often follows a staged process while cloud and firmware components use shorter iterations; this is a hybrid lifecycle.

A useful governance principle is that iteration does not eliminate formal evidence. Each iteration should produce a controlled increment, documented requirements, test results, known limitations, and a decision about readiness.

Figure: A controlled IoT product lifecycle with feedback from operation and retirement into future development.

4. Verification, Validation, and Test Engineering

Verification asks, “Did we build the system right?” It determines whether specified requirements have been met. Validation asks, “Did we build the right system?” It determines whether the system fulfils its intended use and stakeholder needs in its operational context.

Inspection, analysis, demonstration, and test are complementary verification methods:

• Inspection: examination without executing the system, such as checking a schematic or code review.
• Analysis: use of models, calculations, simulation, or reasoned evaluation.
• Demonstration: showing an observable capability, often with limited instrumentation.
• Test: controlled measurement using specified stimuli, procedures, and pass/fail criteria.

Qualification demonstrates that a product design can withstand specified environmental or operational conditions. Acceptance testing determines whether a delivered system is acceptable to the customer. Commissioning establishes correct installation and configuration at a particular site. These terms should not be used interchangeably.

4.1 The test basis

Every test should specify:

• objective and requirement identifier;
• unit under test and software or hardware version;
• test environment, instruments, calibration status, and configuration;
• preconditions and input stimuli;
• procedure and recorded observations;
• expected result and objective pass/fail criterion;
• handling of anomalies, deviations, and retests;
• evidence, reviewer, date, and repository location.

A test case without a measurable oracle is an experiment but not a reliable pass/fail test. For stochastic or machine-learning behaviour, acceptance may instead use statistical criteria, confidence bounds, or a specified evaluation dataset; the criterion must still be defined in advance.

4.2 Test levels and types

Testing should progress from small and controlled to integrated and realistic:

1. Unit testing: verifies a function, driver, module, or hardware block.
2. Component testing: verifies a sensor, radio module, power subsystem, or service.
3. Interface testing: exercises protocols, timing, data types, errors, and version compatibility.
4. Integration testing: examines interactions among components.
5. System testing: evaluates the complete system against requirements.
6. Validation or operational acceptance: uses representative users, environments, workflows, and data.
7. Regression testing: repeats selected tests after change to detect unintended effects.
8. Exploratory testing: investigates behaviour not fully captured by scripted cases.
9. Stress, endurance, and environmental testing: probes capacity, duration, temperature, vibration, humidity, power variation, and recovery.
10. Security testing: includes threat modelling, static and dynamic analysis, authentication tests, update verification, fuzzing, and penetration testing within authorised boundaries.

A test pyramid is useful: many fast unit tests, fewer integration tests, and a smaller number of expensive end-to-end tests. It is not a substitute for field validation because an IoT system can pass laboratory tests yet fail due to interference, installation variation, user behaviour, or cloud dependency.

4.3 Coverage and test prioritisation

Code coverage indicates which program elements were executed, but high coverage does not prove correctness. Requirements coverage, interface coverage, state-transition coverage, fault coverage, environment coverage, and risk coverage are also important.

Risk-based testing prioritises hazards using a structured assessment. A simple risk-priority calculation sometimes used in failure-mode analysis is:

Here, S, O, and D are ordinal ratings for severity, occurrence, and detectability. The result is a prioritisation aid, not a probability and not a universal safety metric. Ordinal scales do not necessarily have equal intervals, so RPN values should not be interpreted as precise quantitative risk. High-severity hazards require attention even when their calculated score is modest.

Fault-tree analysis begins with an undesired top event and works backward through logical causes. Failure-mode and effects analysis begins with component failure modes and works forward to local and system effects. Both methods benefit from independent review and explicit assumptions.

5. Reliability, Availability, and Maintainability

Reliability is the probability that an item performs its required function for a specified time under stated conditions. For a constant failure rate λ and an exponential lifetime model, reliability is:

Here, t is operating time and λ is the constant failure rate in inverse time. This model assumes statistically independent failures and a constant hazard rate; it is often unsuitable during early-life defects, wear-out, or changing environmental stress.

Mean time to failure under this model is:

For repairable systems, availability is commonly approximated by:

where MTBF is mean time between failures and MTTR is mean time to repair. Both quantities must use the same time unit. This expression assumes a stable long-run process and does not automatically include planned maintenance, logistics delays, or common-cause failures.

For independent series components, where every component must function, system reliability is:

Independence is a strong assumption. Shared power, software, network, environmental, or configuration causes can invalidate it. Redundancy also requires careful analysis: two sensors do not provide true fault tolerance if they share the same power rail, calibration error, or communication path.

Worked example: availability

An edge gateway has an MTBF of 8,000 h and an MTTR of 4 h. Under the stated steady-state approximation:

A = 8000/(8000 + 4) = 8000/8004 ≈ 0.9995

Thus availability is approximately 99.95%. This does not mean that every user will experience 99.95% service availability: network outages, cloud downtime, planned maintenance, and correlated fleet failures must be included in an end-to-end availability model.

6. Configuration, Change, and Release Management

Configuration management establishes controlled identities and versions for hardware, firmware, cloud infrastructure, test assets, documentation, and production settings. A baseline is a formally approved configuration that can be reproduced and changed only through an authorised process.

A change-control workflow normally includes change description, rationale, affected items, safety and security impact, regression scope, approval authority, implementation plan, rollback plan, and post-change verification. Version numbers should allow operators to identify compatibility and security status.

Over-the-air updates create special obligations:

• authenticate the update source;
• verify image integrity and, where appropriate, confidentiality;
• prevent rollback to vulnerable versions unless explicitly authorised;
• preserve power-loss recovery through atomic or dual-bank mechanisms;
• support staged deployment, monitoring, pause, and rollback;
• maintain device identity and audit records;
• define behaviour when a device is offline for a long period.

A product is not maintainable if its update process cannot be safely exercised. Update testing should include interrupted downloads, corrupted images, insufficient storage, incompatible versions, expired credentials, clock errors, and simultaneous fleet updates.

7. Security, Safety, Privacy, and Governance

Security and safety are lifecycle properties rather than final inspection activities. Threat modelling should consider assets, trust boundaries, adversaries, attack paths, impact, mitigations, residual risk, and monitoring. Typical controls include hardware-backed identity, least privilege, secure boot, signed updates, encrypted communication, key rotation, network segmentation, logging, vulnerability response, and secure defaults.

Safety analysis asks how faults or malicious actions can cause unacceptable harm. A security control can itself affect safety: certificate expiration may disable a critical service; aggressive rate limiting may suppress an emergency message; a failed update may remove a protective function. Safety and cybersecurity engineers should therefore exchange hazard and threat information.

Privacy governance includes purpose limitation, data minimisation, retention control, access management, transparency, lawful processing, and deletion or de-identification where applicable. Location, health, occupancy, and behavioural data can be sensitive even when a device contains no obvious personal identifier because datasets may be combined.

Professional responsibility includes honest disclosure of limitations, vulnerability reporting, evidence preservation, accessibility, and avoidance of unsafe deployment. Regulatory obligations depend on jurisdiction and product category; engineers must identify applicable radio, electrical safety, environmental, data-protection, medical, automotive, industrial, and cybersecurity requirements rather than assume one universal rule.

8. Product Lifecycle Economics and Sustainability

Lifecycle decisions should include total cost of ownership rather than only purchase price. Relevant costs include engineering, certification, tooling, manufacturing, connectivity, cloud storage, field service, energy, security maintenance, returns, incident response, and end-of-life processing.

Design for sustainability includes low-power operation, repairable construction, long-term component availability, recyclable materials, efficient data transmission, realistic retention policies, and support for secure reuse or refurbishment. Cloud data also has an environmental cost; transmitting and storing every raw sample may be technically unnecessary.

End-of-life planning should define customer communication, service shutdown, credential revocation, data export and deletion, device reset, hazardous-material handling, software archival, and responsibilities among manufacturer, operator, and service provider. “No longer sold” is not the same as “securely retired.”

9. Illustrative Case: Refrigerated Vaccine-Transport Monitoring

Background

A logistics provider proposes battery-powered IoT nodes for monitoring vaccine containers during transport. Each node measures temperature, records time-stamped data, communicates through a gateway when available, and raises an alarm when exposure limits are exceeded. This is an illustrative case, not a report of a particular organisation.

Problem

An initial prototype transmitted every measurement directly to the cloud. Field trials showed that cellular coverage was intermittent, batteries depleted faster than expected, and operators received duplicate alarms after reconnection. A temperature sensor also drifted after repeated thermal cycling. The prototype technically demonstrated sensing but did not satisfy the operational mission.

Analysis

Stakeholders included logistics operators, warehouse staff, quality managers, service technicians, public-health authorities, and recipients. Hazards included missed excursions, false alarms, data loss, unauthorised alteration, and inability to establish a trustworthy chain of custody.

The team converted needs into measurable requirements. Examples were:

• record a measurement at a defined interval with a specified accuracy and timestamp quality;
• buffer data locally through a defined outage duration;
• preserve records across a device restart;
• generate one correlated alarm per excursion episode, with escalation rules;
• detect sensor plausibility failures;
• protect records and updates against unauthorised modification;
• report battery state and communication status;
• provide calibration and maintenance evidence.

The architecture allocated immediate excursion detection and buffering to the device, synchronisation and store-and-forward to the gateway, fleet policy and audit to the platform, and human acknowledgement to the application. This reduced dependence on continuous connectivity.

Approach and solution

The revised design used a bounded local queue, monotonic sequence numbers, authenticated records, and an explicit reconciliation procedure. Alarm logic included hysteresis and an excursion state machine so that a single event was not repeatedly announced. A sensor plausibility check compared rate of change and redundant indicators where available; it did not silently replace a failed measurement.

Testing was staged. Unit tests covered queue boundaries and state transitions. Integration tests interrupted power and connectivity during transmission. Environmental testing examined thermal cycling, condensation, and battery behaviour. Security testing attempted replay, image substitution, credential misuse, and unauthorised configuration. Validation used representative routes, operator workflows, and simulated regulatory records.

Acceptance criteria included data completeness after reconnection, alarm timeliness under stated network conditions, correct recovery after power loss, traceable calibration, and secure retirement. The release was staged to a small fleet before wider deployment, with rollback criteria based on error rates and alarm integrity.

Outcome

The redesigned system did not eliminate all risk; instead, it made assumptions visible and failures detectable. Operators could distinguish a genuine temperature excursion from a connectivity outage, quality staff could audit records, and maintainers could replace batteries and update firmware under controlled procedures. The major improvement was not a single component but the integration of requirements, architecture, testing, operations, and governance.

Learning points

1. Connectivity is a system condition, not a guaranteed service.
2. Local buffering and reconciliation must be designed and tested together.
3. Alarm quality includes correctness, deduplication, escalation, and human usability.
4. Calibration, timestamps, and provenance can be as important as sensor resolution.
5. Security, safety, and lifecycle maintenance must be addressed before deployment.

10. Contemporary Developments and Research Directions

Digital twins are increasingly used to connect physical assets with models, telemetry, maintenance records, and simulations. Their value depends on model validity, data quality, identity management, and clear distinction between measured and inferred states. A visually impressive dashboard is not automatically a reliable digital twin.

Artificial intelligence is being applied to anomaly detection, predictive maintenance, adaptive sampling, and test generation. Its use introduces dataset shift, explainability, false positives, adversarial manipulation, model drift, and difficult validation questions. An AI-based alarm should have a defined operating envelope, fallback behaviour, monitoring metrics, and a human-governed response process. Generated test cases and code also require review, licensing checks, security analysis, and reproducible evidence.

Software bills of materials, vulnerability disclosure programmes, secure-by-design guidance, remote attestation, confidential computing, and zero-trust architectures are becoming more relevant to connected products. Research challenges include dependable edge intelligence, energy-aware security, federated learning with meaningful privacy guarantees, autonomous fleet maintenance, and lifecycle assurance for systems whose components are supplied by many organisations.

Best-Practice Checklist

• Define the mission, stakeholders, boundaries, assumptions, and operating environment.
• Make requirements measurable, feasible, prioritised, and bidirectionally traceable.
• Analyse interfaces and failure behaviour before selecting implementation details.
• Combine unit, integration, system, security, environmental, endurance, and validation testing.
• Use risk analysis to prioritise tests, but do not reduce safety to a numerical score.
• Control hardware, firmware, cloud configuration, test evidence, and documentation as one baseline.
• Design secure, observable, recoverable, and staged update mechanisms.
• Include maintainability, privacy, sustainability, and retirement from the beginning.
• Treat field data and incidents as feedback for controlled lifecycle improvement.
• Preserve independent review for high-consequence decisions.

Chapter Summary

Systems engineering integrates stakeholder needs, requirements, architecture, implementation, verification, validation, operation, and retirement. In IoT and embedded systems, emergent properties arise at interfaces among devices, networks, cloud services, people, and operational environments. Requirements must therefore be measurable and traceable, while architecture must explicitly allocate functions, responsibilities, failure responses, and quality attributes.

Verification establishes conformance to specified requirements; validation establishes fitness for intended use. A credible test programme combines multiple levels and methods, uses objective acceptance criteria, and prioritises risk without treating simplistic scores as probabilities. Reliability, availability, maintainability, fault analysis, configuration control, and staged release are essential to dependable deployment.

Security, safety, privacy, regulatory compliance, sustainability, and end-of-life planning are lifecycle concerns. The refrigerated-transport case demonstrates that operational success depends on integrated design and evidence, not merely on a functioning sensor prototype. Contemporary practices such as digital twins, AI-assisted engineering, software bills of materials, and secure update systems offer benefits but introduce new assurance and governance obligations.

Key Terms

Systems engineering: An interdisciplinary method for managing system development and lifecycle performance.

Stakeholder: A person, organisation, or group that affects or is affected by the system.

Requirement: A necessary, stated, and verifiable condition or capability.

Traceability: The ability to link needs, requirements, design, implementation, tests, and evidence.

Architecture: The organised structure of system elements, functions, interfaces, and relationships.

Emergent property: A property that arises from interactions among system elements.

Verification: Evidence that specified requirements have been satisfied.

Validation: Evidence that the system fulfils its intended purpose in context.

Qualification: Demonstration that a design withstands specified conditions.

Acceptance testing: Testing used to determine whether a delivered system is acceptable.

Regression testing: Repeated testing after change to detect unintended effects.

Configuration management: Controlled identification, versioning, and change of system items.

Reliability: Probability of performing a required function for a specified time and condition.

Availability: Proportion or probability of time that a repairable service is operational.

Maintainability: Ease and speed with which a system can be restored or serviced.

Fault-tree analysis: Top-down analysis of causes leading to an undesired event.

FMEA: Forward analysis of failure modes and their effects.

Secure boot: Startup process that permits only authenticated software to execute.

Technical debt: Future cost created by expedient technical decisions or deferred work.

Digital twin: A data-connected model representing a physical asset or process.

Review Questions

Short Answer Questions

1. Distinguish verification from validation in an IoT product.
2. Why are interfaces a major source of system failures?
3. What information should a well-defined test case contain?
4. State the assumptions behind the exponential reliability model.
5. Why is configuration management important for over-the-air updates?

Long Answer Questions

1. Explain the systems-engineering technical process for an IoT product from mission analysis to retirement.
2. Discuss how requirements traceability supports testing, change impact analysis, and regulatory evidence.
3. Compare unit, integration, system, security, environmental, and validation testing.
4. Explain how security, safety, privacy, and sustainability should be integrated into the product lifecycle.
5. Analyse the advantages and limitations of sequential, iterative, and hybrid lifecycle models for embedded products.

Analytical / Application Questions

1. Design a risk-based test strategy for a connected industrial actuator that must enter a safe state during communication loss.
2. An IoT service has an MTBF of 12,000 h and an MTTR of 6 h. Calculate its approximate steady-state availability and discuss why this may differ from user-perceived availability.
3. For a remote health-monitoring device, propose requirements, architecture allocations, update controls, privacy safeguards, and retirement procedures that would support a defensible lifecycle case.

Multiple Choice Questions with Answers

Question 1

Which statement best distinguishes verification from validation?

A. Verification checks fitness for purpose, while validation checks code style.

B. Verification checks specified requirements, while validation checks intended use in context.

C. Verification occurs only after deployment, while validation occurs only before design.

D. Verification concerns hardware only, while validation concerns software only.

Correct Answer: B. Verification checks specified requirements, while validation checks intended use in context.

Question 2

Which requirement is most testable?

A. The device shall be user-friendly.

B. The gateway shall communicate efficiently.

C. The device shall record a measurement every 60 s ± 5 s when powered.

D. The application shall provide excellent alarms.

Correct Answer: C. The device shall record a measurement every 60 s ± 5 s when powered.

Question 3

For a constant failure rate λ, which expression represents reliability at time t under the exponential model?

A. R(t) = λt

B. R(t) = 1 − e^-λt

C. R(t) = e^-λt

D. R(t) = 1/λt

Correct Answer: C. R(t) = e^-λt

Question 4

A repairable gateway has MTBF = 8000 h and MTTR = 4 h. Its approximate steady-state availability is:

A. 90.00%

B. 95.00%

C. 99.50%

D. 99.95%

Correct Answer: D. 99.95%

Question 5

What is the principal purpose of regression testing?

A. To replace requirements analysis

B. To detect unintended effects after a change

C. To measure only radio transmission power

D. To eliminate the need for acceptance testing

Correct Answer: B. To detect unintended effects after a change

Question 6

Which practice most directly supports safe over-the-air firmware deployment?

A. Using unsigned images to simplify installation

B. Deploying to the entire fleet without monitoring

C. Using authenticated images, staged rollout, and recovery handling

D. Deleting the previous image before verification

Correct Answer: C. Using authenticated images, staged rollout, and recovery handling

Question 7

Why should a risk-priority number not be treated as a precise probability?

A. It is based on ordinal ratings whose intervals may not be equal.

B. It always excludes severity.

C. It can be calculated only for software.

D. It has units of hours.

Correct Answer: A. It is based on ordinal ratings whose intervals may not be equal.

Question 8

Which activity is primarily an example of validation?

A. Reviewing source-code formatting

B. Checking a schematic against a design rule

C. Testing whether representative operators can complete the real workflow

D. Inspecting a component label

Correct Answer: C. Testing whether representative operators can complete the real workflow

Question 9

In a series system with independent components, system reliability is calculated by:

A. Adding all component reliabilities

B. Multiplying component reliabilities

C. Subtracting the smallest reliability from one

D. Averaging only the two best components

Correct Answer: B. Multiplying component reliabilities

Question 10

Which is an essential lifecycle consideration when retiring an IoT device?

A. Increasing its default privileges

B. Leaving credentials active for possible future use

C. Revoking credentials and managing data and physical disposal

D. Removing all audit records immediately

Correct Answer: C. Revoking credentials and managing data and physical disposal