Mobile Security, Privacy, Ethics and Governance

Introduction and Context

Mobile computing has transformed communication, commerce, healthcare, education, transportation and public administration. A contemporary mobile ecosystem includes smartphones, tablets, wearables, vehicle systems, mobile applications, cellular and Wi-Fi networks, cloud services, application programming interfaces (APIs), digital identity systems and location platforms. This ecosystem is strategically important because it combines highly personal data with devices that are continuously connected, sensor-rich and frequently used for authentication and financial transactions.

Mobile security is therefore broader than protecting a handset from malware. It involves protecting confidentiality, integrity, availability, authenticity, safety and privacy across the complete lifecycle of a device and its services. A secure design must consider hardware, firmware, operating systems, radio interfaces, applications, cloud infrastructure, users, organisations and regulators. Privacy and ethics extend the analysis further: a system may be technically secure but still be intrusive, discriminatory, manipulative or legally non-compliant.

This chapter presents a risk-based approach to mobile security and governance. It examines threats at multiple layers, cryptographic and authentication controls, secure boot and trusted execution, zero-trust architecture, privacy engineering, ethical questions, regulatory obligations and practical governance.

Learning Objectives

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

1. Analyse threats across mobile devices, radio interfaces, applications and backend infrastructure.

2. Explain the roles and limitations of cryptography, authentication, secure boot and trusted execution.

3. Apply zero-trust principles to mobile and cloud-connected systems.

4. Design privacy controls based on data minimisation, purpose limitation and lifecycle governance.

5. Evaluate surveillance, consent, digital inclusion and algorithmic fairness issues.

6. Develop a security and privacy governance approach for a mobile service.

7. Critically assess contemporary developments such as passkeys, eSIM, mobile threat defence and artificial intelligence.

1. The Mobile Security Problem

1.1 Security objectives

The traditional security objectives are confidentiality, integrity and availability. Confidentiality prevents unauthorised disclosure; integrity protects data and software from unauthorised modification; availability ensures that authorised users can access services when needed. Mobile systems require additional objectives:

• Authenticity: assurance that a user, device, application or service is genuine.
• Accountability: ability to associate actions with responsible entities while respecting privacy.
• Resilience: ability to continue operating or recover after compromise.
• Safety: prevention of physical harm, particularly in medical, automotive and industrial applications.
• Privacy: appropriate control over collection, use, inference and disclosure of information.

These objectives can conflict. Continuous location monitoring may improve emergency response but reduce privacy. Strong authentication may reduce fraud but exclude users with disabilities or limited connectivity. Security governance is consequently a process of managing risk and justified trade-offs, not simply maximising technical controls.

1.2 Attack surface and trust boundaries

A mobile attack surface includes every interface through which an adversary can influence a system. Important interfaces include:

• cellular signalling and subscriber identity mechanisms;
• Wi-Fi, Bluetooth, near-field communication and ultra-wideband radios;
• USB, charging and debugging interfaces;
• sensors, cameras, microphones and biometric readers;
• operating-system services and inter-process communication;
• application stores, third-party libraries and software supply chains;
• cloud APIs, identity providers and mobile device management platforms; and
• human interfaces, including notifications, permissions and authentication prompts.

A trust boundary separates components with different security assumptions. For example, a mobile application should not automatically trust another application merely because both execute on the same device. Similarly, a cloud API should authenticate and authorise every request rather than trust a device because it previously connected from a corporate network.

2. Threats Across the Mobile Ecosystem

2.1 Device and hardware threats

Loss or theft remains a major mobile risk. An attacker may attempt to bypass the lock screen, extract data from storage, abuse backup copies or impersonate the owner. Devices can also be compromised through malicious charging accessories, exposed debug ports, insecure bootloaders, counterfeit components or firmware vulnerabilities.

Mobile operating systems generally use application sandboxing, permission controls, encrypted storage and hardware-backed key protection. However, a sandbox is not an absolute barrier. Operating-system vulnerabilities, excessive privileges, insecure inter-process communication and unsafe native code can allow a malicious application to escape its intended restrictions.

Sensors create distinctive risks. A microphone can reveal conversations, an accelerometer can support inference about typing or movement, and location histories can expose employment, health, religious and social patterns. Even data that appears non-sensitive may become sensitive when combined with other datasets.

2.2 Radio and network threats

Wireless communication is exposed to eavesdropping, spoofing, replay, jamming, rogue access points and protocol downgrade. Public Wi-Fi can support credential theft through phishing portals or malicious access points. Bluetooth devices may be tracked, impersonated or attacked through implementation flaws. Cellular systems provide authentication and encryption, but protection varies by generation, configuration and the specific interface being used.

A useful distinction is between radio confidentiality and end-to-end confidentiality. Radio encryption protects traffic over a wireless link. End-to-end encryption protects content between communicating endpoints, potentially across several networks and service providers. Radio encryption alone does not protect data after it reaches a network intermediary or application server.

Availability attacks include deliberate interference, signalling overload, denial-of-service against APIs and battery-draining attacks. In safety-critical systems, availability must be considered alongside graceful degradation and emergency operation.

2.3 Application and supply-chain threats

Mobile applications may contain insecure storage, weak authentication, improper certificate validation, exported components, excessive permissions, insecure deep links, vulnerable third-party libraries or hard-coded secrets. An application can also be technically free of malware yet violate privacy by collecting data unrelated to its stated purpose.

The software supply chain introduces risks through development tools, open-source dependencies, build servers, signing keys, application stores and update mechanisms. A signed application is not necessarily benign: a legitimate developer account may be compromised, or a trusted application may contain excessive functionality. Security assessment must therefore address provenance, dependency management, code review, vulnerability disclosure and runtime behaviour.

2.4 Backend and infrastructure threats

Mobile applications commonly rely on APIs, cloud storage, analytics platforms, push-notification services and identity providers. Common weaknesses include broken object-level authorisation, excessive data returned by APIs, insecure tokens, poor secrets management, misconfigured storage, weak tenant isolation and inadequate monitoring.

Backend compromise can affect millions of devices simultaneously. Consequently, mobile security cannot be delegated entirely to the device operating system. Organisations must inventory APIs, classify data, enforce least privilege, monitor anomalous activity, patch services and maintain tested incident-response procedures.

2.5 Human and socio-technical threats

Phishing, fraudulent support calls, malicious QR codes, fake applications and consent manipulation exploit human trust. Mobile interfaces are small, notifications are frequent and users often operate under time pressure. Security warnings therefore compete with convenience and attention.

Insiders, abusive partners and coercive actors require special consideration. A device may be securely configured yet provide a stalker access through shared accounts, family-tracking tools or cloud backups. Threat modelling should include not only anonymous external attackers but also privileged insiders and people with physical or social access to the victim.

3. Cryptography and Identity

3.1 Cryptographic foundations

Cryptography provides mechanisms rather than complete security. Symmetric encryption uses the same secret key for encryption and decryption and is efficient for bulk data. Public-key cryptography uses a key pair: a public key may be distributed, while a private key must remain protected. Digital signatures provide integrity and authentication of the signer; encryption provides confidentiality. Hash functions map input data to fixed-length values and support integrity checks, password protection schemes and signatures, but a hash is not encryption.

A secure protocol normally requires authenticated encryption, secure key establishment, certificate or key verification, replay protection and sound key lifecycle management. Algorithms should be selected from current standards and implemented using vetted libraries. Creating a proprietary cipher or modifying a standard protocol without expert review is unsafe.

For a symmetric cipher with key space of size 2^k, exhaustive search has approximately 2^k possible keys in the idealised case. This observation explains why key length matters, but real security also depends on algorithm design, implementation, side-channel resistance, random-number generation and key protection. Security estimates must account for advances in computation and cryptanalysis.

3.2 Key management

Key management is often more difficult than selecting an algorithm. It includes generation, distribution, storage, rotation, revocation, backup, recovery and destruction. Mobile devices should use hardware-backed keystores where available. Keys should be separated by purpose, such as storage encryption, application authentication and signing. A key that is readable by ordinary application code provides weaker protection than a key whose sensitive operations occur inside a secure hardware or trusted execution environment.

Lost credentials require recovery mechanisms, but recovery must not become a bypass. Organisations should define who may reset credentials, what evidence is required, how recovery is logged and how users are notified.

3.3 Authentication and authorisation

Authentication verifies identity; authorisation determines permitted actions. The factors used for authentication are commonly categorised as knowledge, possession and inherence. Multi-factor authentication combines independent factors, reducing the effect of a stolen password. Push approvals can still be abused through notification fatigue, while one-time codes may be intercepted through phishing or account takeover. Phishing-resistant methods, including hardware security keys and passkeys based on public-key credentials, provide stronger protection because the credential is bound to the legitimate origin.

Biometrics are useful for local convenience but are not secrets in the same sense as passwords. A face or fingerprint cannot normally be changed after compromise. Biometric templates should therefore be protected, preferably processed locally, and combined with a device-held cryptographic key. Systems must provide accessible alternatives and avoid treating biometric failure as proof of fraud.

Authorisation should follow least privilege, deny-by-default and separation of duties. A mobile user who may view an account should not automatically be allowed to export all records or change ownership. Short-lived tokens, audience restrictions, device posture checks and step-up authentication can reduce the consequences of token theft.

4. Secure Boot and Trusted Execution

4.1 Chain of trust

Secure boot establishes a chain of trust from an immutable or strongly protected root to boot firmware, operating-system components and authorised applications. Each stage verifies the signature or integrity of the next stage before executing it. If verification fails, the device may refuse to boot, enter recovery or use a verified fallback image.

Secure boot protects against persistent modification of early software, but it does not guarantee that authorised software is free from vulnerabilities or abusive data practices. A signed malicious update, stolen signing key or compromised vendor can still create risk. Signing keys require strong protection, multi-person controls, key rotation and emergency revocation procedures.

4.2 Trusted execution environments

A trusted execution environment (TEE) separates sensitive operations from the general-purpose operating system. It may protect cryptographic keys, biometric matching, payment operations or attestation functions. A secure element is a specialised hardware component designed for protected key storage and cryptographic operations.

Trusted hardware reduces attack risk but does not eliminate it. Vulnerabilities may exist in firmware, interfaces or trusted applications. Developers must minimise trusted code, validate inputs and define what the hardware actually attests. Remote attestation allows a service to evaluate evidence about device or software state before granting access, but attestation raises governance questions concerning transparency, repair, interoperability and discrimination against older devices.

5. Zero-Trust Mobile Architecture

Zero trust rejects implicit trust based on network location or prior access. Its central principle is to verify explicitly, use least privilege and assume that compromise is possible. In a mobile architecture, this means authenticating users, devices, applications and services for each relevant request; evaluating context such as risk and device posture; limiting privileges; and continuously monitoring outcomes.

A practical zero-trust design may include:

1. strong, phishing-resistant identity credentials;

2. device registration with hardware-backed keys where feasible;

3. application and API authentication using mutually verifiable credentials;

4. policy-based authorisation with least privilege;

5. segmentation of sensitive services;

6. encryption in transit and at rest;

7. centralised but privacy-conscious logging; and

8. rapid revocation and incident response.

Zero trust is not a product and does not mean endlessly challenging users with prompts. Excessive friction encourages unsafe workarounds. Policies should be risk-sensitive, accessible and evaluated against false positives, user burden and service availability.

6. Privacy Engineering

6.1 Privacy as a system property

Privacy concerns the appropriate collection, use, disclosure and retention of information, including information inferred about individuals. It is not equivalent to secrecy. A user may willingly share location for navigation while objecting to its retention for advertising or disclosure to an employer.

Privacy engineering integrates privacy requirements into architecture rather than adding a policy after implementation. Core principles include:

• Data minimisation: collect only what is necessary.
• Purpose limitation: use data for specified, legitimate purposes.
• Storage limitation: retain information no longer than justified.
• User control: provide meaningful access, correction, deletion and consent choices where applicable.
• Transparency: explain collection, inference, sharing and automated decisions.
• Privacy by default: use the least intrusive settings as the initial configuration.
• Security: protect data throughout its lifecycle.

6.2 Technical privacy controls

Pseudonymisation replaces direct identifiers but does not make data anonymous if re-identification remains possible. Anonymisation is difficult when location, timestamps and behavioural patterns are rich. Aggregation, spatial or temporal coarsening, access controls and retention limits can reduce risk.

Differential privacy provides a formal way to limit the influence of one individual’s data on a released statistic. In an informal interpretation, a privacy parameter commonly denoted by epsilon controls the privacy-utility trade-off: smaller epsilon generally provides stronger privacy but may reduce statistical accuracy. The guarantee depends on the mechanism, composition across repeated releases and correct management of the privacy budget. Differential privacy is not a universal solution for raw data publication, identity abuse or insecure endpoints.

Other controls include local processing, federated learning, secure multiparty computation and encryption during computation. These technologies have different assumptions and costs. Federated learning can reduce central collection, but model updates may leak information and the coordinator may still observe participation patterns. Privacy-preserving technologies must therefore be evaluated as part of a complete threat model.

6.3 Consent and meaningful choice

Consent should be informed, specific, freely given and revocable where the governing framework requires these conditions. A long notice presented during account creation is not automatically meaningful consent. Dark patterns, confusing defaults, bundled permissions and repeated prompts can manufacture acceptance.

Some processing cannot ethically be justified merely because a user clicked “accept,” especially where there is a power imbalance, essential-service dependency or foreseeable harm. Organisations should establish necessity, proportionality and an appropriate lawful basis, and should offer non-discriminatory alternatives where practical.

7. Ethics, Inclusion and Surveillance

7.1 Ethical principles

Responsible mobile computing is guided by respect for autonomy, beneficence, non-maleficence, justice and accountability. Autonomy requires meaningful choice and understandable information. Beneficence supports useful outcomes; non-maleficence requires prevention of foreseeable harm. Justice concerns fair distribution of benefits and burdens, while accountability requires explainable responsibility for decisions and failures.

Ethical review should ask: Who benefits? Who bears risk? Who may be unable to opt out? Could data be repurposed? Are vulnerable groups disproportionately affected? Can an individual challenge an automated decision? These questions are especially important in health, education, employment, policing and welfare systems.

7.2 Surveillance and dual use

Location services, biometric identification, communications metadata and behavioural analytics can support safety and public services. They can also enable political repression, discrimination, intimate-partner abuse or commercial manipulation. Governance should require necessity, proportionality, independent oversight, access controls, auditability, retention limits and remedies.

Security controls themselves may be dual-use. Device exploitation tools can support legitimate investigations but also facilitate unlawful surveillance. Vendors and public authorities should apply authorisation controls, vulnerability disclosure processes, export and human-rights assessments, and transparent reporting where legally possible.

7.3 Digital inclusion

Security and privacy measures must account for affordability, disability, literacy, language, rural connectivity, age and access to identity documents. Requiring a recent device, constant connectivity or a single biometric modality can exclude legitimate users. Inclusive design may provide offline operation, low-bandwidth modes, accessible interfaces, alternative authentication factors, human support and proportional recovery processes.

8. Regulation and Governance

Legal requirements vary by jurisdiction, but recurring governance themes include protection of personal data, breach notification, children’s data, consumer protection, electronic communications, cybersecurity, accessibility, records management and sector-specific duties. Organisations operating internationally must map data flows and determine applicable obligations rather than assuming that one privacy notice satisfies all jurisdictions.

A mature governance programme normally includes:

• asset and data inventories;
• risk assessments and threat modelling;
• security and privacy requirements in procurement;
• secure development lifecycle controls;
• vulnerability management and coordinated disclosure;
• supplier and cloud-service assurance;
• access reviews and segregation of duties;
• incident response, evidence preservation and notification procedures;
• retention and deletion schedules;
• staff training and acceptable-use policies; and
• independent audit, metrics and continuous improvement.

Governance should identify accountable owners. A chief information security officer may lead security risk, while privacy officers, legal teams, product owners, engineers and senior management share responsibility. Boards and executives should receive meaningful measures such as critical vulnerabilities by age, privileged-access review completion, phishing-resistant authentication coverage, incident response time, unsupported devices and privacy request performance. Counting only the number of controls can create a false impression of safety.

9. Security and Privacy Assessment Method

A useful assessment proceeds through the following stages:

Define scope. Identify devices, applications, networks, data, users, suppliers and jurisdictions.

Classify assets and harms. Consider confidentiality, integrity, availability, safety, financial loss, discrimination, reputational damage and loss of autonomy.

Model threats. Identify adversaries, capabilities, incentives, attack paths and trust boundaries. STRIDE can support technical threat identification, while privacy threat modelling should additionally consider linkability, identifiability, detectability, information disclosure, unawareness and non-compliance.

Select controls. Prefer layered controls: secure defaults, least privilege, strong identity, encryption, secure updates, monitoring, recovery and human safeguards.

Validate. Conduct code review, penetration testing, dependency analysis, configuration review, privacy impact assessment, usability testing and adversarial testing.

Operate and improve. Monitor, patch, revoke, investigate, communicate and learn from incidents. Reassess when functionality, suppliers, regulations or threat conditions change.

Risk can be prioritised qualitatively or quantitatively. A simple qualitative model considers likelihood and impact, but numerical scores should not be treated as objective measurements unless the scales and evidence are well defined. A low-probability event with catastrophic safety consequences may require action even when its numerical product appears modest.

10. Illustrative Case Study: Mobile Health Monitoring Service

Background

A healthcare provider introduces a smartphone application that receives data from a wearable heart-rate sensor, provides alerts to clinicians and offers patients personalised feedback. The service uses cloud analytics and permits family members to view selected information.

Problem

The initial design requests continuous location, contacts and microphone access, although these functions are not necessary for heart-rate monitoring. Data are retained indefinitely for unspecified “service improvement.” Family sharing is enabled by default, and account recovery relies on security questions. An attacker who obtains an API token may access records for multiple patients because object-level authorisation is incomplete.

Analysis

The service has device, application, API, cloud and human risks. Health data are highly sensitive. Continuous location creates inference about clinic visits and daily routines. Default family sharing creates an autonomy and domestic-abuse risk. Security questions are weak recovery factors. The API weakness threatens confidentiality and integrity at scale. False alarms and unavailable monitoring may also create safety consequences.

Approach and solution

The provider conducts a threat model and privacy impact assessment. It removes unnecessary permissions, processes preliminary sensor analysis locally, and collects location only during an explicitly enabled emergency function. Health records are encrypted in transit and at rest, with keys protected through a managed key service and restricted administrative access.

The application uses phishing-resistant authentication where supported, local biometric unlocking backed by a device key, and a carefully designed alternative for users unable to use biometrics. API requests use short-lived tokens, explicit patient-resource authorisation and server-side checks. Family sharing becomes opt-in, granular and revocable, with notifications when access changes. Retention periods are defined according to clinical and legal needs, followed by secure deletion or justified archival.

The provider introduces signed updates, dependency scanning, secure coding review, logging that avoids unnecessary health content, incident-response exercises and clinician oversight of automated alerts. Accessibility testing includes older adults and users with limited digital literacy.

Outcome

The revised design reduces data collection, limits the impact of token compromise, improves patient control and establishes auditable accountability. It does not eliminate risk: sensors can fail, cloud providers remain dependencies, and clinical decisions require human judgement. The organisation therefore maintains continuous monitoring and periodic reassessment.

Learning points

1. Privacy requirements should shape architecture from the beginning.

2. Authorisation must be enforced for every resource, not inferred from a valid login.

3. Consent and sharing defaults can create serious safety risks.

4. Hardware and encryption controls must be combined with governance and usability.

5. A secure system must address availability, accessibility and clinical consequences, not only confidentiality.

11. Contemporary Developments and Open Challenges

Passkeys and hardware-backed credentials are reducing dependence on reusable passwords, but deployment must support account recovery, device migration and accessibility. eSIM and remotely provisioned identities improve flexibility while increasing the importance of carrier, provisioning and supply-chain security. Mobile threat-defence platforms can detect risky applications, networks or device states, yet they raise questions about telemetry, false positives and employee monitoring.

Artificial intelligence is used for malware detection, fraud analysis, behavioural anomaly detection and privacy-preserving data synthesis. Machine-learning systems introduce model theft, poisoning, evasion, bias and privacy leakage. Automated security decisions should be tested for disparate impact, monitored for drift and subject to human review where consequences are significant. Generative AI can accelerate secure coding and incident analysis, but it can also generate vulnerable code, expose confidential prompts or produce inaccurate advice. Human validation remains essential.

Post-quantum cryptography is relevant to long-lived confidential data because adversaries may record encrypted traffic for later decryption if future capabilities permit. Organisations should inventory cryptographic dependencies, identify migration constraints and follow authoritative standardisation guidance. Migration must preserve interoperability and avoid rushed adoption of unverified algorithms.

Open research problems include usable continuous authentication, privacy-preserving sensing, secure cross-device ecosystems, formal assurance of mobile software, equitable digital identity, secure repairability and governance of commercial surveillance technologies. These are socio-technical problems requiring collaboration among engineers, legal scholars, policymakers, human-computer interaction researchers and affected communities.

Best-Practice Checklist

A mobile service should, at minimum:

• define assets, users, threats, harms and trust boundaries;
• minimise permissions and data collection;
• use established cryptographic libraries and protected key storage;
• implement secure boot, signed updates and vulnerability response;
• separate authentication from authorisation and enforce resource-level checks;
• use phishing-resistant authentication for high-value access;
• apply zero-trust principles to devices, applications, APIs and administrators;
• provide transparent, revocable and accessible privacy choices;
• test for abuse, exclusion, supply-chain compromise and failure conditions;
• limit retention and protect backups, logs and analytics;
• maintain incident response, recovery and communication plans; and
• measure real outcomes rather than merely counting compliance activities.

Chapter Summary

Mobile security is an ecosystem responsibility spanning hardware, firmware, operating systems, radios, applications, APIs, cloud infrastructure and human behaviour. Threats include device loss, wireless interception, rogue networks, malware, supply-chain compromise, insecure APIs, surveillance and social engineering. Cryptography provides confidentiality, integrity and authentication, but depends on sound key management and implementation.

Secure boot and trusted execution establish protected foundations, while zero trust removes implicit confidence based on network location and requires explicit verification, least privilege and continuous assessment. Privacy engineering adds data minimisation, purpose limitation, retention control, meaningful consent and privacy-preserving computation. Ethical governance addresses autonomy, justice, safety, surveillance, inclusion and accountability. Effective programmes combine technical safeguards with threat modelling, impact assessment, secure development, incident response, regulation and continuous oversight.

Key Terms

Threat model: Structured analysis of assets, adversaries, attack paths and possible harms.

Trust boundary: Interface separating components with different security assumptions.

Confidentiality: Protection against unauthorised disclosure.

Integrity: Protection against unauthorised alteration.

Availability: Ability of authorised users to access a service when required.

Authenticated encryption: Encryption that also verifies message integrity and authenticity.

Digital signature: Cryptographic evidence supporting integrity and signer authentication.

Key management: Generation, storage, distribution, rotation, revocation and destruction of cryptographic keys.

Multi-factor authentication: Authentication using two or more independent factor categories.

Passkey: Phishing-resistant public-key credential used for authentication.

Secure boot: Verified execution chain from a protected root to authorised software.

Trusted execution environment: Isolated environment for sensitive computation and key operations.

Remote attestation: Evidence about a device or software state supplied to a verifying service.

Zero trust: Security approach based on explicit verification, least privilege and assumed compromise.

Data minimisation: Collection and processing limited to what is necessary.

Purpose limitation: Restriction of data use to specified legitimate purposes.

Pseudonymisation: Replacement of direct identifiers without guaranteeing anonymity.

Differential privacy: Formal privacy guarantee limiting the influence of one individual on released results.

Privacy impact assessment: Systematic evaluation of privacy risks and mitigations.

Governance: Structures, policies, responsibilities and oversight used to direct and control risk.

Review Questions

Short Answer Questions

1. Distinguish radio confidentiality from end-to-end confidentiality.

2. What is the purpose of secure boot?

3. Why are biometrics not equivalent to secret passwords?

4. State three principles of zero-trust architecture.

5. Define data minimisation and purpose limitation.

Long Answer Questions

1. Explain the major threats affecting mobile devices, radio interfaces, applications and backend infrastructure.

2. Discuss how cryptography, key management, authentication and authorisation work together in a mobile service.

3. Explain the role and limitations of secure boot, trusted execution environments and remote attestation.

4. Analyse the ethical and governance challenges associated with mobile location and biometric surveillance.

5. Describe a complete security and privacy assessment method for a cloud-connected mobile application.

Analytical / Application Questions

1. A banking application uses passwords, SMS codes and a cloud API. Develop a threat model and recommend stronger authentication, authorisation and recovery controls.

2. Design a privacy-preserving architecture for a wearable health-monitoring service. Justify data collection, local processing, retention and consent decisions.

3. An organisation wants to deny access to all devices that cannot support the newest security feature. Evaluate this policy using security, inclusion, privacy and governance criteria, and propose a proportionate alternative.

Multiple Choice Questions with Answers

Question 1

Which statement best distinguishes radio encryption from end-to-end encryption?

A. Radio encryption protects content across every backend service

B. End-to-end encryption protects content between communicating endpoints

C. Radio encryption authenticates every application user

D. End-to-end encryption eliminates the need for key management

Correct Answer: B. End-to-end encryption protects content between communicating endpoints

Question 2

What is the primary purpose of secure boot?

A. To increase wireless bandwidth

B. To verify authorised software before execution

C. To anonymise application data

D. To replace access control

Correct Answer: B. To verify authorised software before execution

Question 3

Which practice most directly reflects zero-trust architecture?

A. Trusting every device inside the corporate network

B. Allowing permanent access after the first successful login

C. Explicitly verifying requests and applying least privilege

D. Disabling all monitoring to protect privacy

Correct Answer: C. Explicitly verifying requests and applying least privilege

Question 4

Why should biometric authentication generally be combined with a device-held cryptographic key?

A. Biometrics are always perfectly secret

B. Biometric characteristics cannot normally be changed after compromise

C. Cryptographic keys make consent unnecessary

D. Biometrics cannot be processed locally

Correct Answer: B. Biometric characteristics cannot normally be changed after compromise

Question 5

Which control most directly limits the harm from a stolen API token?

A. Returning all records in one API response

B. Using short-lived tokens and resource-level authorisation

C. Disabling software updates

D. Collecting additional location data

Correct Answer: B. Using short-lived tokens and resource-level authorisation

Question 6

What does data minimisation require?

A. Collecting every potentially useful data item

B. Collecting only data necessary for the specified purpose

C. Retaining data indefinitely for future analysis

D. Publishing pseudonymised data publicly

Correct Answer: B. Collecting only data necessary for the specified purpose

Question 7

Which statement about pseudonymisation is correct?

A. It guarantees that re-identification is impossible

B. It replaces direct identifiers but may still permit re-identification

C. It is identical to encryption

D. It removes the need for access controls

Correct Answer: B. It replaces direct identifiers but may still permit re-identification

Question 8

Which is an ethical risk of default family sharing in a health application?

A. Improved cryptographic key length

B. Potential loss of autonomy and exposure to coercive access

C. Reduced need for audit logs

D. Automatic elimination of clinical error

Correct Answer: B. Potential loss of autonomy and exposure to coercive access

Question 9

What is a central governance purpose of a privacy impact assessment?

A. To guarantee that a system has no vulnerabilities

B. To identify privacy risks and evaluate mitigations before or during deployment

C. To replace incident response planning

D. To maximise data retention

Correct Answer: B. To identify privacy risks and evaluate mitigations before or during deployment

Question 10

Which approach best supports digital inclusion in mobile authentication?

A. Requiring one biometric modality for every user

B. Requiring constant high-bandwidth connectivity

C. Providing accessible alternative authentication and recovery methods

D. Rejecting older devices without assessing risk

Correct Answer: C. Providing accessible alternative authentication and recovery methods