Login, Trust, and Security

## Epic: Login, Trust and Security

**8 participants tested, March 2026**

### Summary
User testing shows that business owners take a deliberate and cautious approach
when logging in. Participants expect strong security, but experience friction when
security feels unnecessarily complex or forces tools they are uncomfortable with.

**Note:** Trust concerns specific to the migration email are covered in Epic:
Migration Email Clarity and Trust. This epic covers trust and friction at the
login layer only.

**Outcome:** Users feel their information is secure and can log in without hesitation.

---

### User Story: Feel confident the login is secure
**Confidence:** High | **Support Risk:** High

As a business owner
I want to feel confident my information is protected
So I trust the system enough to continue

#### Notes
- Participants applied deliberate trust checks before logging in
- The BC Services Card is broadly seen as a meaningful trust signal
- Confidence increased after successful authentication
- Reinforce security confidence without adding unnecessary steps

#### Evidence
All participants expressed security expectations during the login portion of
testing. One said directly: "I like the fact that it's linked to the services
card — that gives me comfort in terms of the security issue side of things."
*(Research report Slides 14–15; BCR 001, 004, 005)*

#### Actions
- [ ] Reinforce visible trust signals during login
- [ ] Ensure security steps feel proportional to the task
- [ ] Validate that users feel confident immediately after login

---

### User Story: Reduce password frustration
**Confidence:** Med | **Support Risk:** Med

As a business owner
I want fewer passwords to manage
So logging in does not feel like a burden

#### Notes
- Participants expressed fatigue with managing many passwords
- "There's so many passwords in modern life to remember"
- Authentication methods that reduced password repetition were welcomed
- Avoid adding new credentials; treat simplicity as part of good security design
- Note: password manager tools were flagged as not suitable for this user group

#### Evidence
3 out of 8 participants explicitly mentioned frustration with managing multiple
passwords across government services.
*(Research report Slides 14–15; BCR 002, 003, 004)*

#### Actions
- [ ] Minimise the number of credentials users must manage
- [ ] Avoid introducing new passwords unnecessarily
- [ ] Validate perceived effort during login

---

### User Story: Avoid forcing users into unwanted authentication tools
**Confidence:** Med | **Support Risk:** Low

As a business owner
I want login options that respect my preferences
So I do not resist or delay logging in

#### Notes
- Some participants were hesitant about app-based authentication
- Not all users were comfortable using a mobile app to log in
- The preferred authentication experience was not fully tested in this round
- Do not position authentication as app-required by default
- One participant raised a serious access gap: non-resident directors cannot
obtain a BC Services Card, which means the entire process fails for them
before it starts

#### Evidence
3 out of 8 participants were reluctant about using the BC Services Card mobile
app. One said: "I'm not really a big fan of that BC services app." A separate
participant raised a more serious issue: non-resident directors cannot obtain a
BC Services Card, which means the entire migration process fails for them at
step one.
*(Research report Slides 14–15, 26–27 BCR 001, 004, 005;
BCR 007 non-resident director issue confirmed in Research report Slide 25)*

#### Actions
- [ ] Avoid positioning authentication as app-required by default
- [ ] Reduce friction for users hesitant about mobile apps
- [ ] Validate login comfort across different user types
- [ ] Address non-resident director access gap — flagged as a blocker

Start with Research report Slides 14–15 and 25–27, which document login trust, password, app-authentication, and non-resident access findings. No source files, tests, or entry points are identified; the epic is complete when the login experience addresses the listed friction and access concerns and user confidence is validated.

Written by the indexing model from the issue text.