A cybersecurity measure can look neutral because it is applied equally to an entire population. Yet an identical rule does not always produce equivalent protection. A code sent only to a phone, a very long password without an accessible alternative, a technical instruction in one language, or an automatic lockout without human review can exclude the very person who most needs a service. The problem is not that security is inconvenient; it arises when inconvenience becomes exclusion, dependency, or loss of access to a medical appointment, benefit, school, or livelihood. Designing inclusive security means identifying barriers before an incident turns them into a crisis. It also requires safe support, proportionate decisions, and recovery routes that neither humiliate people nor expose their data.
Apparent universality conceals different contexts#
People do not use technology from equivalent conditions. Some depend on a screen reader, share a family device, live with unstable coverage, lack current digital documentation, have limited storage, or communicate best in another language. Less visible situations also matter: a person may be subject to coercive control, lack a bank account of their own, work hours that prevent calling support, or need a carer’s help without handing over credentials. A policy that assumes a personal phone, permanent email, rapid reading, and continuous availability turns these conditions into undeclared requirements. Formal equality in the rule can hide practical inequality. Before imposing verification, it is worth asking which resources it assumes, what happens when they fail, and who is left without a reasonable route. The answer is not to weaken every protection, but to offer options that preserve both the security goal and each person’s dignity.
People do not use technology from equivalent conditions. Some depend on a screen reader, share a family device, live with unstable coverage, lack current digital documentation, have limited storage, or communicate best in another language.
Accessibility is a property of security#
An inaccessible screen is not merely an experience flaw: it can prevent confirmation of a payment, recognition of a legitimate alert, or recovery of an account after fraud. Controls should be operable by keyboard, announce error states to assistive technology, provide adequate contrast, and avoid making an essential task depend on an image, colour, or precise gesture. Time limits deserve the same attention. A challenge that expires before it can be read, copied, or translated encourages abandonment and improvisation. Language matters as well. Explaining why a datum is requested, what cancelling will do, and how to seek help reduces mistakes without revealing unnecessary information. Accessibility testing should include high-consequence real tasks, such as signing in, changing a recovery contact, and reporting unexpected activity. An automated audit helps, but it cannot replace observing diverse people trying to complete those tasks safely.
Language, literacy, and operational clarity#
Security vocabulary often offers a false choice between jargon and empty simplification. Clear communication can name the risk, explain the action, and remain precise. A useful notice states which service issued it, what event was detected, what remains unconfirmed, which official channel to use, and what deadline exists. A notice that merely commands “verify now” shifts the burden to its recipient and resembles a fraudulent message too closely. Translation must be complete and reviewed; translating buttons is not enough if errors, conditions, and support channels remain in another language. Recognisable examples, formats compatible with plain-language reading, and human support that does not punish questions are also useful. Clarity does not remove individual responsibility, but makes it possible to exercise. When an organization communicates understandably, it narrows the space exploited by haste, deception, and abusive intermediaries.
The material cost of a control cannot be ignored#
Stronger authentication often improves protection for important accounts, but its design can shift costs onto people with fewer resources. Requiring a recent phone, mobile data, a heavy application, or an unshared line can exclude people using old devices, limited plans, or public connectivity. Charging for account recovery, an international message, or an accessible alternative worsens exclusion. Responsible assessment counts money, time, battery, travel, and third-party support, not only the provider’s cost. Where risk permits, equivalent alternative methods should exist, clearly published and protected against misuse: compatible passkeys, physical devices, securely issued recovery codes, or assisted verification with safeguards. Offering an alternative does not mean creating a weak secret route; it means designing a verifiable path with comparable guarantees and appropriate oversight.
Case one: the code that never arrives#
An older person accesses a health portal from a shared library computer. The system replaces the password with a code sent exclusively to a phone that failed that morning. The appointment is necessary, and the only available help requires installing an application or calling during working hours. The measure protects against some improper access, but it has removed all continuity for a legitimate need. Inclusive design would have allowed preparation of more than one recovery method, safely held single-use codes, phone assistance with verified identity, and jargon-free explanations of deadlines. Support staff should not ask for a password or receive a code as though they were the affected person. They should follow a traceable process that confirms identity, limits information viewed, and restores autonomy. The case shows that recovery and accessibility belong to the control from the start.
Case two: the alert that cannot be interpreted#
A cooperative activates an unusual-access warning. The message uses a red icon, an abbreviated English phrase, and a link opening a window incompatible with one worker’s screen reader. Faced with uncertainty, the worker ignores the notice for fear of blocking an urgent task. It is later discovered that the alert was legitimate and that delay increased the review work. Blaming the recipient would be a convenient and unfair conclusion. The failure was communicating a critical action in one form only, without alternative text, an independent channel, or an explanation of consequences. Correction includes a notice readable through different technologies, an official address that can be typed manually, brief instructions in working languages, and a confidential way to confirm doubts. Security improves when reporting a barrier is treated as a valuable signal, not as resistance to a control.
Case three: support that becomes dependency#
A newly arrived student needs help activating an education account. Because the guide is available only in a language still being learned, a classmate offers to complete the process and keeps the password “just in case.” The immediate solution permits access, but creates privacy, conflict, and loss-of-control risk. Safe support does not require sharing secrets. It can consist of a translated guide, an institutional video call with interpretation, a help point where steps can be completed on the person’s own device, and recovery that recognizes changed circumstances. Anyone giving assistance should be able to guide without seeing passwords, codes, or private content. The organization should make clear that asking for help never justifies surrendering credentials. This case concerns students, temporary workers, migrants, and family carers: a language or administrative barrier does not authorize substituting another person’s identity.
Age and context do not describe incapacity#
Age can influence prior experience, sight, dexterity, or confidence, but it does not justify assuming that an older person is incapable or that a younger person understands every risk. Likewise, a disabled person is not an exceptional case to be considered at the end. Decisions should start from observable needs and consent, not stereotypes. Useful design lets people enlarge text, choose a contact method, practise recovery calmly, and request an explanation without condescension. In contexts of violence or control, notifications, histories, and shared devices can create physical or social danger. It is therefore essential to enable discreet communications, review which data is displayed, and provide specialist support without demanding more disclosure than necessary. Inclusion protects best when it recognizes that autonomy may vary by situation and that the affected person retains the right to decide.
Design alternatives without opening gaps#
A safe alternative needs clear criteria. It should have a specific purpose, check identity proportionately, record only what is essential, and be reviewable by an authorized person. It is not prudent to answer every difficulty by disabling controls, creating generic accounts, or allowing third parties to act with someone else’s key. It is stronger to combine options: more than one authentication factor, verified recovery contacts, reasonable time limits, trained human assistance, and confirmations outside a suspicious channel. Each route should document who may use it, what evidence it requires, and how misuse is detected. Design must also anticipate a lost device, a language change, the end of a care relationship, or inability to receive messages. Testing these situations without simulating attacks or collecting sensitive data finds failures before harm occurs. A repeated exception is no longer an exception; it is evidence that the service needs redesign.
Governance, privacy, and accountability#
Inclusive security cannot depend only on the goodwill of support staff. It needs owners, budget, training, and measurement. It is useful to record how many people abandon a process, how long recovery takes, which methods fail most often, and which barriers are reported, without turning records into personal surveillance. Data needs a defined purpose, limited access, and temporary retention. An incident review should separate facts, impacts, and improvements; it should not accumulate intimate details or identify the person who sought help. High-impact decisions, such as suspending an account or demanding new identity evidence, deserve human review and an accessible appeal mechanism. Transparency about limits, timelines, and options reduces rumours and fraud. It also makes it possible to check whether a measure reduces risk or merely shifts its cost onto people with fewer resources to bear it.
Sources and verifiable practice#
Decisions can be checked against institutional and primary sources. NIST publishes risk-management guidance and the Cybersecurity Framework; ENISA gathers European guidance on cybersecurity and human factors; CISA offers everyday protection resources; INCIBE provides help for people in Spain; and the AEPD explains data-protection responsibilities. The W3C accessibility guidelines help assess digital barriers. These references do not replace listening to each context, but they help justify controls, document alternatives, and review effects with evidence.
Before a barrier becomes a crisis#
The decisive question is not whether a measure looks advanced, but whether affected people can use it safely when tired, away from home, with limited connectivity, in another language, or during an emergency. Mature practice identifies important assets, provides prepared recovery, explains controls clearly, and tests diverse journeys. When friction appears, the response limits impact, protects privacy, and learns without blame. Tools remain valuable, but their value depends on not turning protection into a privilege. Designing for most people is an operational beginning; designing also for those at the margins is what turns that beginning into real security for everyday life.
