Nobody Asked the Person Being Watched: A Threat Taxonomy for Care Monitoring at Home

TL;DR: Systems that watch over someone at home, from baby monitors to personal alarms for older people to monitoring in mental health care, all have the same awkward property: the person being watched is not the person using the product, and may not be able to consent fully or freely. Threat modeling frameworks and regulation both split this domain down the middle, and nothing covers it end to end. I have published a taxonomy that does: 74 threats in nine suits along the care chain, from the sensor to the responder, plus 9 structural hazards, each with a mitigation principle and concrete design measures. 45 of the 74 can leave someone without help when they go wrong. It is the reference for my card game Elevation of Care. Walk it against a system you know and tell me what it misses. The full taxonomy, with a page per suit and downloads in four formats, is at Care Assistant Threat Taxonomy.

A camera in a child’s bedroom. A pendant on an older man’s wrist that calls for help when he falls. Motion sensors that learn a woman’s routine and tell her daughter when the kitchen has been quiet too long. A wearable that a community mental health team asks a young adult to wear after discharge. These are very different products, sold under very different rules, and they share one design problem.

Someone else buys the product, sets it up and reads its alerts. The person it watches bears the risk. A baby cannot consent at all. A child’s capacity grows every year. An older person’s may be fading, and a person in mental health care may have full capacity one month and not the next. Every design decision about who sees what, who can switch it off and what happens when nobody answers is made on their behalf.

The problem is not that the people who build these systems skip threat modeling. The problem is that the frameworks were not built for a product whose user is not its subject. Apply STRIDE to a home monitoring design and it will surface something: a spoofed sensor, a stream someone else can watch, a hub that can be unplugged. It will rarely surface an alert that counts as delivered when it reaches a silenced phone, a “false alarm” button that quietly desensitises detection for good, an ex-partner who can still see into the home after a separation, or monitoring that started for a newborn and is still running when the child is fifteen.

I have published a taxonomy that does: 74 threats in nine suits, plus 9 structural hazards, each with the principle a sound design follows and concrete measures that put it into practice. It has a home of its own on this site, with a page for every suit, and this post explains why it exists and what it covers.

Why the gap exists

Care monitoring is not short of rules. It is short of one map that covers the whole domain, in the form a design review needs. The rules we have split it in two, and the frameworks we have were built for a different shape of system:

• 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 security regimes built on it (the UK’s PSTI regulations, Australia’s smart device standards from March 2026, the EU Cyber Resilience Act from 2027, 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 as soon as the manufacturer’s intended purpose is medical, and in every market the consumer regimes exclude those products. A baby sock that reports oxygen saturation and heart rate to parents crossed that line: the US FDA’s 2021 warning letter treated Owlet’s Smart Sock as a medical device because of those notifications, and a later version was cleared as an over-the-counter infant pulse oximeter in 2023. Monitoring tied to treatment or relapse in mental health care is more likely still to sit on the medical side.
• 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. None of them is a threat taxonomy.
• STRIDE and LINDDUN are the two threat frameworks most teams know. STRIDE asks about attackers; LINDDUN asks about privacy. Neither has a question for an authorised watcher using the system to control someone, for consent that goes stale as capacity changes, or for the silence of a broken sensor reading as good news.

Between them, they leave three gaps. Nothing spans the domain from the sensor to the responder in one classification, across babies, older people, people with a disability or long-term illness, and people in mental health care. Nothing treats the person watched over as a party to the design rather than as data. And almost nothing treats the human response chain (the family, the monitoring centre, the responder at the door) as part of the system it has to threat model.

The result is not that these systems are unsafe by intention. They are unexamined by default. The people who build them are very good at sensors, apps and alerting. What they rarely have is a framework for asking: what can go wrong at this point in the care chain, for this person, when they cannot speak for themselves?

When the framework does not exist, the question does not get asked systematically. And when the question does not get asked, the findings do not get made.

What the taxonomy is

It is a structured catalogue of what can go wrong when someone is watched over at home, organised by where in the care chain the threat lives. 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. A further group of structural hazards belongs to the domain as a whole, so no single suit can fix them.

Every entry has the same parts:

• 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.
• Mappings to STRIDE, LINDDUN, CAPEC and CWE where they exist, and a life-safety mark where failure can leave someone without help.

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.

The mappings are left empty where nothing fits, on purpose. 34 of the 74 entries have neither a CAPEC attack pattern nor a CWE weakness, and only 13 have a CAPEC pattern at all. That is not a gap in the mapping. It is the point: most of what goes wrong here is not an attack on a component. A follow-up post maps every entry to STRIDE, LINDDUN, CAPEC and CWE and shows where each one falls short.

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.

Who it is for and how to use it

If you build these systems, whether that is a baby monitor, a personal alarm, an ambient sensing service, a telecare platform or a remote monitoring programme for a care provider, this was written for you first. You do not need a security background. Each entry tells you what to look for, what a sound design does about it, and concrete ways that has been done.

If you buy or run them, as a care provider, a health or social care commissioner, or a monitoring centre, the Response, Care Circle and Lifecycle suits are about you as much as the vendor. Your rota, your call handlers, your key-safe codes and your process for when someone moves into a care home are part of the system.

If you are a security or privacy engineer who has been handed one of these products to threat model and found that STRIDE gives you the obvious and LINDDUN gives you the data protection view, but neither asks what happens when the phone is on silent, this names what you have been trying to name.

If you advocate for the people being watched, as a clinician, a social worker, a parent or a family member, the Resident suit and the structural hazards give you words for the questions you already ask: who decided this, can the person say no, and when does it stop?

Using it is simple:

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.

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 and may not be able to consent fully or freely: social alarms and telecare, personal emergency response systems, baby and child monitors, passive ambient monitoring, wearable sensors, camera and audio monitors, and routine or mental-state analytics. It is jurisdiction-neutral, so legal roles appear in general terms, such as legal representative, background check and emergency number. It does not cover the platform threats every connected product shares (cloud, CI/CD, email, AI agents), which my Software Factory, Elevation of Email Flow and Elevation of Autonomy taxonomies 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. What you are reading 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 an eight-year-old through the camera in her bedroom in 2019; the manufacturer said the account had been opened with credentials reused from another service. 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 references at the end point to the original sources. 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.

Most of the entries have no headline incident, and that is worth saying plainly. A missed alert at three in the morning rarely makes the news, and an older person who unplugs a sensor because she does not want to be watched does not file a disclosure. 5 of the 74 entries name a public case. The rest are design weaknesses that the people who build and run these systems will recognise, which does not make them less real.

What the taxonomy covers

The full taxonomy lives in the Care Assistant Threat Taxonomy section of this site, with a page for every suit. Each suit page has its entries, the public cases they were seen in, and how they map to STRIDE, LINDDUN, CAPEC and CWE. These are the nine suits and the structural hazards:

• 01 · Sensing (SN): 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): 6 threats, 2 of them life-safety. Cameras, microphones, talk-back, live streams and recordings.
• 03 · Interpretation (IN): 7 threats, 7 of them life-safety. Baselines, rules, models, feedback loops and what counts as an emergency.
• 04 · Alerting (AL): 7 threats, 4 of them life-safety. Getting an alert to a person who acts on it.
• 05 · Response (RS): 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): 8 threats, 4 of them life-safety. The watchers: parents, family, friends, paid carers, agencies and clinical teams.
• 07 · Resident (RE): 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): 8 threats, 2 of them life-safety. What the record reveals, where copies live and how long they last.
• 09 · Lifecycle (LC): 6 threats, 3 of them life-safety. Install, claim, moves, resale, death and the end of the service.

The whole domain

• Structural hazards (T): 9 hazards, 5 of them life-safety. Properties of the domain that cut across every suit.

That is 74 entries in all, 45 of them marked life-safety. The overview page also covers the regulatory landscape by region, the sources for every known case, the licence and the version history.

Final thoughts

This is a first published version, not a final one. The products change every year, with new sensors, AI that claims to spot decline before a family can, and monitoring programmes moving from hospitals into homes, and I have no doubt there are threats I have missed and entries that belong in a different suit.

So take it, walk a suit against a system you know well, and tell me where it falls short. Corrections, missing threats and worked examples from practitioners are all welcome, and I would particularly like to hear from people who work with the groups being watched: carers, clinicians, social workers and parents. Reach out to me on LinkedIn.

The person being watched has been left out of the design for long enough. Let’s start asking them, or asking on their behalf. More on the game the taxonomy came from in a later post. Stay tuned!

Resources

The taxonomy is also available to download in four formats, all with the licence embedded. The overview page lists them too.

Licence

© 2026 Jonathan Brett Crawley. The taxonomy is licensed under CC BY-NC-ND 4.0 with additional permissions: you can share it freely for non-commercial purposes, threat model with it (including for paying clients), use it internally and for training in any organisation, and quote entries with credit in paid work. Shipping it in a product needs permission. The full terms are on the overview page.

References

Every known case named in the taxonomy 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.

Frameworks and standards

• ETSI EN 303 645 scope, cyber security for consumer IoT (baby monitors in scope; devices primarily intended for medical use out of scope)
• LINDDUN privacy threat modeling, KU Leuven
• MITRE CAPEC (version 3.9) and MITRE CWE (version 5.0)
• IEC 62851-1 social alarm systems, CEN/TS 17470 service model for social care alarms and IEC 63240-1:2024 AAL reference architecture

Regulation, by region

• PSTI (Security Requirements for Relevant Connectable Products) Regulations 2023 and Schedule 3, excepted products; MHRA: Borderlines with medical devices
• Cyber Resilience Act timeline, Freshfields, and the CRA medical-device exemption; MDCG 2019-11 Rev.1 explained, OpenRegulatory
• Security standards for smart devices, Australian Department of Home Affairs, and scope and exclusions, A&O Shearman
• FCC picks ioXt Alliance for the Cyber Trust Mark, Broadband Breakfast; FDA 2026 General Wellness and CDS guidance, Arnall Golden Gregory
• JC-STAR and Singapore CLS mutual recognition, METI

Known cases, by suit

• EOC-SN-K Lost Line: 3G network retirements stranding medical alert systems (United States, 2022), Pennsylvania Health Law Project
• EOC-AV-A A Stranger’s Voice: Stranger speaks to a child through a bedroom camera (Ring, 2019), ABC7
• EOC-AV-K Open Stream: ThroughTek Kalay device impersonation, CVE-2021-28372 (2021), Mandiant
• EOC-AV-K Open Stream: TRENDnet camera feeds posted online, FTC settlement (2013), US Federal Trade Commission
• EOC-AV-Q Clips That Travel: iBaby Monitor M6S alert clips reachable in cloud storage (2020), Bitdefender
• EOC-T3 Intended Purpose Drift: FDA warning letter on Owlet Smart Sock (2021), later Dream Sock De Novo clearance (2023), US Food and Drug Administration and Dream Sock De Novo clearance, Owlet (2023)

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.