> ## Content Index
> Fetch the complete content index at: https://www.ostering.com/llms.txt
> Use this file to discover other available public pages before exploring further.
# Care Assistant Threat Taxonomy
- URL: https://www.ostering.com/taxonomies/care-assistant/
- Published: 2026-11-05T21:00:00.000Z
- Updated: 2026-11-05T20:57:22.430Z
- Description: Threat taxonomy for care monitoring at home: 65 threats in nine suits along the care chain, plus 9 structural hazards, with mitigations.
- Author: Brett Crawley
[Taxonomies](/taxonomies/) › Care assistant
This is the reference for the Elevation of Care card game: every card's threat, the mitigation principle a sound design follows, design measures, and mappings to STRIDE, LINDDUN, CAPEC and CWE.
Care assistant systems watch over someone at home on someone else's behalf: baby and child monitors, personal alarms and telecare, fall detection and ambient sensors, cameras with talk-back, routine and wellbeing analytics, and monitoring under a care plan. The person watched over is not the one using the system, and may not be able to consent fully or freely: a baby or a child, an older person, a person with a disability or long-term illness, a person in mental health care. This taxonomy catalogues what can go wrong: **65 threats in nine suits along the care chain, plus 9 structural hazards**, each with the principle a sound design follows and concrete measures that put it into practice. 45 of the 74 entries are marked life-safety.
Every entry is one of the game's cards, written out so that it can also be used without the game, and the taxonomy card in the game's box links here with a QR code. Why the taxonomy exists, and what the existing frameworks miss, is in [Nobody Asked the Person Being Watched](/nobody-asked-the-person-being-watched/).
## The suits
**The care chain**
- [01 · Sensing (SN)](/taxonomies/care-assistant/eoc-sensing/): 8 threats, 8 of them life-safety. Sensors, wearables, radio links, the home unit and the home it sits in.
- [02 · Sight and Sound (AV)](/taxonomies/care-assistant/eoc-sight-and-sound/): 6 threats, 2 of them life-safety. Cameras, microphones, talk-back, live streams and recordings.
- [03 · Interpretation (IN)](/taxonomies/care-assistant/eoc-interpretation/): 7 threats, 7 of them life-safety. Baselines, rules, models, feedback loops and what counts as an emergency.
- [04 · Alerting (AL)](/taxonomies/care-assistant/eoc-alerting/): 7 threats, 4 of them life-safety. Getting an alert to a person who acts on it.
- [05 · Response (RS)](/taxonomies/care-assistant/eoc-response/): 7 threats, 6 of them life-safety. Monitoring centres, responders, entry to the home and the hand-off to emergency services.
- [06 · Care Circle (CC)](/taxonomies/care-assistant/eoc-care-circle/): 8 threats, 4 of them life-safety. The watchers: parents, family, friends, paid carers, agencies and clinical teams.
- [07 · Resident (RE)](/taxonomies/care-assistant/eoc-resident/): 8 threats, 4 of them life-safety. The person watched over (baby, child, older person, person with a disability or in mental health care) and everyone else the sensors see.
- [08 · Data and Inference (DA)](/taxonomies/care-assistant/eoc-data-and-inference/): 8 threats, 2 of them life-safety. What the record reveals, where copies live and how long they last.
- [09 · Lifecycle (LC)](/taxonomies/care-assistant/eoc-lifecycle/): 6 threats, 3 of them life-safety. Install, claim, moves, resale, death and the end of the service.
**The whole domain**
- [Structural hazards (T)](/taxonomies/care-assistant/eoc-structural-hazards/): 9 hazards, 5 of them life-safety. Properties of the domain that cut across every suit.
Four suits follow an alert from the sensor to the responder: Sensing, Interpretation, Alerting and Response. The person watched over and the people watching sit at either end, as Resident and Care Circle. Sight and Sound carries the person straight to the watchers through cameras and microphones, bypassing the rest of the chain, and Data and Inference and Lifecycle run under all of it.
## What an entry contains
- **A name**, short enough to say in a design review.
- **A threat**, stated as a property of a component or a design decision, the way a builder meets it. Not "an attacker could", but "the system does".
- **A mitigation principle**: what a sound design does, stated so that different designs can satisfy it in different ways.
- **Design measures**: two or three concrete ways of satisfying the principle. They are examples of what works, not the only acceptable answers.
- **A life-safety mark** (†) where failure can leave someone without help, and **mappings** to STRIDE, LINDDUN, CAPEC and CWE where they exist.
Where a threat has been seen in the wild, the entry names the public incident or disclosure (5 of the 74 entries do). The others are design weaknesses with no single headline incident, which does not make them less real: most of what goes wrong in this domain is a missed alert, a stale consent or an unanswered phone, and those rarely make the news.
The format is deliberate. A threat on its own is an accusation, and a list of measures on its own is a checklist that fits one product and no other. The principle sits between them: it says what must be true, and the measures show what that looks like in practice. Against a real design, each entry produces a finding, or a one-line "no exposure" with the reason, which is worth writing down too.
Each entry carries an ID such as EOC-AL-A or EOC-T4. The ID is the card: EOC stands for Elevation of Care, the card game the taxonomy comes from, then comes the suit code and the card's rank, from Ace down to 7, or T1 to T9 for the structural hazards. EOC-AL-A is the Ace of Alerting, the card AL·A at the table. The IDs use dashes rather than dots so that search engines index each one as a single term: search for EOC-AL-A and you find every page that cites that entry. The ID is a stable identifier, not a severity. In the game the ranks follow severity, because play is trick-based; here an ID only names an entry, and it stays the same as the taxonomy grows.
## How to use it
1. Draw the system: the devices, the home network, the cloud, the watchers' phones, the response chain, and the person watched over, with the trust boundaries marked.
2. Take one suit and walk every entry in it against each element it applies to.
3. For each entry, ask whether the design satisfies the principle. Write down a finding, or "no exposure" and the design decision that defeats it.
4. Where there is a finding, start from the measures given and adapt them to your design. They are the shape of a fix, not a prescription.
5. Finish with the structural hazards, played against the design as a whole. They usually explain several findings at once and point to a design change, not a patch per finding.
**Note to product teams:** start with Alerting. Most of the life-safety entries in the other suits end in the same place: an alert that existed, and a person who never saw it.
Each suit page shows its entries as a table graphic. The [downloads](#downloads) carry the same content as text that can be searched, filtered and copied.
## Where suits touch
Some suits touch, and it helps to know which side of the line an entry sits on:
- **Sensing and Interpretation:** sensing decides what the system hears; interpretation decides what it makes of it, including what it makes of silence.
- **Interpretation and Alerting:** interpretation decides that something is an emergency; alerting decides whether a person ever finds out.
- **Alerting and Response:** alerting ends when a person acknowledges; response is what that person, or a service, then does.
- **Sight and Sound and Care Circle:** the camera carries the person straight to the watchers; the care circle is who those watchers are and what they do with it.
- **Care Circle and Resident:** the care circle covers the watchers and their access; the resident covers the person watched over, their consent and their say.
- **Resident and Data and Inference:** the resident suit asks whether the watching is wanted; data and inference asks what the record says about them and who else can read it.
- **Data and Inference and Lifecycle:** data covers what is kept and where; lifecycle covers what happens to it when the household, the device or the provider changes.
## Scope and origin
The taxonomy covers systems that monitor a person at home on someone else's behalf, where the person watched over is not the one using the system: social alarms and telecare, personal emergency response systems, baby and child monitors, passive ambient monitoring, wearable sensors, camera and audio monitors, and routine or wellbeing analytics. It is jurisdiction-neutral, so legal roles appear in general terms, such as legal representative and emergency number. It does not cover the platform threats every connected product shares (cloud, CI/CD, email, AI agents), which the [Software Factory](/taxonomies/software-factory/) and [Email Infrastructure](/taxonomies/email-infrastructure/) taxonomies and Elevation of Autonomy already cover. And it covers products on both sides of the medical-device line, because the threats do not change when the regulator does.
It started as a game. I designed Elevation of Care, a threat modeling card game, because I saw a gap in the games we already have: they cover web applications, cloud, privacy, AI, email and the software supply chain, but none of them walks the chain of care, from the sensor to the person who responds, with the person being watched at the centre. The deck came first, and this taxonomy is its reference: each card's threat became an entry, each card's suit became a suit here, and the mitigation principle and measures were written to answer the questions the card asks. This taxonomy is the game's content, restated so that it can be used without the game.
I want to be clear about one thing: it is not that these issues did not exist. Some are well documented in real products. A stranger spoke to a child through the camera in her bedroom in 2019. A flaw in a widely used camera SDK, CVE-2021-28372, let attackers impersonate devices, including baby monitors, and watch live audio and video. When US carriers retired 3G in 2022, medical alert systems that depended on it stopped working. The sources below point to the originals. What was missing was the translation. Each issue had to be restated as a threat that a designer can test their own system against, and the whole lot collated into a single resource that spans the care chain and every group of people it serves. That is the contribution here: the translation and the collection, not the discovery.
## Where the rules split
Care assistant products fall between three sets of rules, and none of them is a threat taxonomy:
- **Consumer connected-product rules** cover baby monitors, cameras and most home alarms. ETSI EN 303 645 names baby monitors among the consumer devices in its scope, and the regimes built on it (the UK's PSTI regulations, Australia's smart device standards, the EU Cyber Resilience Act, the voluntary US Cyber Trust Mark, Japan's JC-STAR and Singapore's labelling scheme) set a baseline: no default passwords, a way to report vulnerabilities, a stated support period. They say nothing about consent, capacity or who answers an alarm.
- **Medical-device rules** take over when the manufacturer's intended purpose is medical, and the consumer regimes exclude those products. A product can cross that line with one claim: see EOC-T3, Intended Purpose Drift.
- **Care standards** (the EN 50134 series and IEC 62851-1 for social alarms, CEN/TS 17470 for the alarm service chain, IEC 63240-1 for assisted living) describe how a service should work.
## STRIDE, LINDDUN, CAPEC and CWE
Every entry is mapped to STRIDE and LINDDUN, the two threat frameworks most teams know, and to CAPEC 3.9 and CWE 5.0. STRIDE fits 25 of the 74 entries cleanly, 33 only loosely and 16 not at all. LINDDUN fits 20 cleanly, 13 loosely and 41 not at all, and catches 14 entries that STRIDE misses. CAPEC has a pattern that describes 8 directly, only a generic parent for 5, and nothing for 61. CWE names the flaw directly for 12, has only a broader weakness for 25, and nothing for 37. 35 entries are missed by all four: no clean STRIDE or LINDDUN prompt, and no direct CAPEC or CWE match. 27 of them are life-safety entries. What the mapping shows is in [Mapping the Care Assistant Threat Taxonomy to STRIDE, LINDDUN, CAPEC and CWE](/care-assistant-taxonomy-stride-linddun-capec-cwe-mapping/). Each suit page gives its own figures and its mapping table, entry by entry; the Excel, SKOS and STIX downloads carry every mapping as text.
## Downloads
| Download | Format | What it is for |
| --- | --- | --- |
| [PDF](/media/files/care-assistant-threat-taxonomy.pdf) | A4 landscape, a section per suit, with each entry's STRIDE, LINDDUN, CAPEC and CWE mapping | Reading and printing. Also the text version of the tables on these pages. |
| [Excel](/media/files/care-assistant-threat-taxonomy.xlsx) | Workbook, one suit per sheet | Filtering, sorting, copying entries into a threat model, tracking findings. |
| [SKOS (JSON-LD)](/media/files/care-assistant-threat-taxonomy.skos.jsonld) | W3C SKOS concept scheme | Linked data: the hierarchy, references, mitigations, and links to STRIDE, LINDDUN, CAPEC and CWE. |
| [STIX 2.1](/media/files/care-assistant-threat-taxonomy.stix.json) | STIX 2.1 bundle | Security tooling: an attack pattern and a course of action per entry, grouped by suit, with CAPEC and CWE references. |
All four carry the licence. The STIX bundle's extra fields are described by [this JSON Schema](/media/files/ostering-taxonomy-stix-extension.schema.json).
## Licence
© 2026 Jonathan Brett Crawley. This taxonomy is licensed under the [Creative Commons Attribution-NonCommercial-NoDerivatives 4.0 International licence](https://creativecommons.org/licenses/by-nc-nd/4.0/) (CC BY-NC-ND 4.0), with the additional permissions below. You can share the whole taxonomy freely for non-commercial purposes, unchanged and with credit.
| Use | Permission needed? |
| --- | --- |
| Sharing the whole taxonomy non-commercially (OWASP, universities, conferences, individuals) | No |
| Threat modeling with it, including for paying clients | No |
| Internal use and training inside any organisation | No |
| Quoting entries, with credit, in paid courses, reports and talks | No |
| Shipping the taxonomy in a product: a tool's built-in library, a printed deck, a reprint for sale | Yes, ask me |
**Additional permissions.** In addition to the rights the licence gives, and whether or not the use is commercial, the copyright holder grants you permission to:
- Use the taxonomy to threat model systems you build, operate or assess, including for paying clients;
- Use it internally, and for training, inside any organisation;
- Quote individual entries, with credit, in paid courses, reports, findings and talks.
Any other commercial use, including shipping the taxonomy or a substantial part of it in a product (a tool's built-in library, a printed deck, a reprint for sale), needs written permission. Ask me on LinkedIn.
**Credit:** “Care Assistant Threat Taxonomy” by Jonathan Brett Crawley, ostering.com, licensed under CC BY-NC-ND 4.0.
These additional permissions are given alongside the licence. They add to what the licence allows and do not take anything away from it.
## Version
| Version | Date | Change |
| --- | --- | --- |
| 1.0 | 2 November 2026 | First published as reference pages, with PDF, Excel, SKOS and STIX downloads. References are stable identifiers. |
Corrections, missing threats and worked examples are welcome: reach out to me on LinkedIn. Changes are logged here.
## Sources
Every known case named in the tables was checked against a primary or near-primary source on 2 November 2026, and the regulatory facts against the sources below on the same date. The frameworks the taxonomy builds on come first, then the regulation by region, then a source for each known case, then the facts that are still contested.
**Frameworks and standards**
- [ETSI EN 303 645 scope](https://standards.globalspec.com/std/14298875/en-303-645), cyber security for consumer IoT (baby monitors in scope; devices primarily intended for medical use out of scope)
- [LINDDUN privacy threat modeling](https://linddun.org/), KU Leuven
- [MITRE CAPEC](https://capec.mitre.org/) (version 3.9) and [MITRE CWE](https://cwe.mitre.org/) (version 5.0)
- [IEC 62851-1 social alarm systems](https://standards.iteh.ai/catalog/standards/iec/db2c7a41-9663-4c6c-a457-f0aa4c2d3107/iec-62851-1-2014), [CEN/TS 17470 service model for social care alarms](https://standards.iteh.ai/catalog/standards/cen/f1101f63-56ef-4d60-bfb0-cace771b9ca3/cen-ts-17470-2020) and [IEC 63240-1:2024 AAL reference architecture](https://scc-ccn.ca/standardsdb/standards/2056383)
**Regulation, by region**
- [PSTI (Security Requirements for Relevant Connectable Products) Regulations 2023](https://legislation.gov.uk/ukdsi/2023/9780348249767/contents/data.pdf) and [Schedule 3, excepted products](https://legislation.gov.uk/uksi/2023/1007/schedule/3/made); [MHRA: Borderlines with medical devices](https://www.gov.uk/government/publications/borderlines-with-medical-devices/borderlines-with-medical-devices-and-other-products-in-great-britain)
- [Cyber Resilience Act timeline](https://freshfields.us/insights/campaigns/technology-quotient/tech-and-platform-regulation/eu-digital-strategy/cyber-resilience-act), Freshfields, and the [CRA medical-device exemption](https://cdn.presencis.com/regulations/cra/exemptions/medical-devices); [MDCG 2019-11 Rev.1 explained](https://openregulatory.com/mdcg/mdcg-2019-11), OpenRegulatory
- [Security standards for smart devices](https://www.homeaffairs.gov.au/about-us/our-portfolios/cyber-security/security-standards-for-smart-devices), Australian Department of Home Affairs, and [scope and exclusions](https://jdsupra.com/legalnews/australia-new-security-standards-for-3129119), A&O Shearman
- [FCC picks ioXt Alliance for the Cyber Trust Mark](https://broadbandbreakfast.com/fcc-picks-ioxt-alliance-to-head-cyber-trust-mark-program/), Broadband Breakfast; [FDA 2026 General Wellness and CDS guidance](https://www.jdsupra.com/legalnews/don-t-fear-the-regulator-fda-clarifies-6892021/), Arnall Golden Gregory
- [JC-STAR and Singapore CLS mutual recognition](https://www.meti.go.jp/english/press/2026/0318_002.html), METI
**Known cases, by suit**
- EOC-SN-K Lost Line: [3G network retirements stranding medical alert systems (United States, 2022)](https://www.phlp.org/en/news/certain-life-alert-systems-will-no-longer-work-following-3g-shutdown), Pennsylvania Health Law Project
- EOC-AV-A A Stranger's Voice: [Stranger speaks to a child through a bedroom camera (Ring, 2019)](https://abc7.com/ring-security-cameras-studio-city-hacker-camera-hacked/5750794), ABC7
- EOC-AV-K Open Stream: [ThroughTek Kalay device impersonation, CVE-2021-28372 (2021)](https://cloud.google.com/blog/topics/threat-intelligence/mandiant-discloses-critical-vulnerability-affecting-iot-devices), Mandiant
- EOC-AV-K Open Stream: [TRENDnet camera feeds posted online, FTC settlement (2013)](https://search.ftc.gov/news-events/news/press-releases/2013/09/marketer-internet-connected-home-security-video-cameras-settles-ftc-charges-it-failed-protect), US Federal Trade Commission
- EOC-AV-Q Clips That Travel: [iBaby Monitor M6S alert clips reachable in cloud storage (2020)](https://www.bitdefender.com/en-us/blog/labs/severe-vulnerability-in-ibaby-monitor-m6s-camera-leads-to-remote-access-to-video-storage-bucket), Bitdefender
- EOC-T3 Intended Purpose Drift: [FDA warning letter on Owlet Smart Sock (2021), later Dream Sock De Novo clearance (2023)](https://www.fda.gov/inspections-compliance-enforcement-and-criminal-investigations/warning-letters/owlet-baby-care-inc-616354-10052021), US Food and Drug Administration
**Contested or single-source facts**
- In the 2019 bedroom camera case, the account of how access was gained is the manufacturer's: it attributed the intrusion to reused credentials and said it found no compromise of its own systems.
- CVE-2021-28372 was disclosed by Mandiant with CISA. Because the SDK is built into products before they reach consumers, no complete list of affected baby monitors was published.
- The figure of about 2 million alarm and medical alert devices still on 3G in 2022 comes from an industry survey (the Alarm Industry Communications Committee), as reported by the Pennsylvania Health Law Project.