More Rewards Breach: What Save-On-Foods Shoppers' Data Exposed

More Rewards, the loyalty program behind Save-On-Foods and other Pattison Food Group grocery stores in Western Canada, says an intruder accessed member names and, where members gave them, mailing addresses, phone numbers, email addresses and dates of birth. Passwords, card data and purchase history were not accessed, per the company. Members should expect targeted scams.

The company found the unauthorised activity on one server on Tuesday 13 October 2026 and shut that server down the same day. It confirmed which accounts were affected on Friday 16 October and emailed those members that evening. It has not said how many people are affected. This post sets out what the company has published, what it has not, how the reporting rules in Canada work, and what any team running a loyalty or customer profile platform can check this week. The access method has not been disclosed, so we do not guess at it.

The short version

• When: Unauthorised activity on one More Rewards server was discovered on 13 October 2026. The server was shut down that day and a third party cybersecurity firm was brought in, according to the company's incident page.
• Confirmation: On Friday 16 October the company confirmed which member records were accessed and emailed affected members after business hours that evening.
• Data accessed: name, plus mailing address, phone number, email addresses and date of birth where the member had provided them.
• Not accessed, per the company: More Rewards ID passwords, credit card data and transaction history. The company says there is no indication that the servers holding those were accessed, that accounts and points are secure and that no password reset is required.
• How many people: not disclosed. CTV News asked and was not given a number; CBC News, as reported by The Cool Down, also asked and had no figure by publication. More Rewards as a program has more than 3.5 million members, according to Pattison Food Group as cited in that coverage, but that is the size of the membership, not the number affected.
• Regulators: the company says it has notified the appropriate authorities and privacy regulators. It has not named them.
• Credit monitoring: the company says it is working to make credit monitoring available and will post an update when it is in place.
• Scam warning: official emails come only from addresses ending in @mail-morerewards.ca and @morerewards.ca, and the company says it will never ask for passwords, verification codes, banking or card details, a Social Insurance Number or security question answers.

What happened

The company's account lives on an incident page at morerewards.ca/update, last updated on 23 October 2026, and in the email that went to affected members. Both say much the same thing, in a few short paragraphs.

In our own words: on 13 October the More Rewards team found unauthorised activity on one of its servers. It shut the server down that day and opened an investigation with an outside cybersecurity expert. The company describes the incident as quickly contained. On Friday 16 October it confirmed that member personal information on the More Rewards database had been accessed, and identified which accounts were involved. It then emailed each affected member, at every email address on the account, that same evening.

The incident page explains the Friday evening timing directly. It says the company could not confirm the specific affected accounts until that Friday and chose to notify people right away instead of waiting until Monday. That detail matters for anyone writing their own breach playbook: the gap between "we found something" (Tuesday) and "we know whose data it was" (Friday) is three days here, and most of that time is usually spent working out exactly which records a server held and which of them were touched.

The company also says it has strengthened its security and monitoring to help spot unauthorised activity, and that it continues to review the incident and look for further measures. It does not describe what those changes are.

Timeline

What the company has not said

The notice is specific about data fields and careful about what it does not know. As of 24 October, it does not say:

• How the intruder got in. No access method, vulnerability, credential issue or third party involvement has been named.
• Who did it. No group has been named by the company, and we have not seen a credible public claim. We do not speculate.
• Whether data was copied out. The company says data was "accessed". It does not say whether records were exfiltrated, and it does not report any misuse.
• How many members are affected. Not disclosed to CTV News or to CBC.
• What the server was. Only that it was one server, and that the More Rewards database records on it were accessed.
• Which regulators were notified. Only "the appropriate authorities and privacy regulators".
• When credit monitoring will start, and through which provider.

Who is affected

Only members whose records were on the affected server and were accessed are affected, and the company says it has emailed all of them. If you are a member and did not get an email, the company's FAQ suggests checking junk and spam folders.

Which stores use More Rewards

The company's incident page does not list banners. Coverage differs slightly on the list:

Pattison Food Group describes itself as running 11 retail banners and more than 300 food and drug locations across Western Canada and the Yukon, with what it calls an industry-leading loyalty program. The Cool Down, citing CBC, notes that Save-On-Foods requires shoppers to join More Rewards to shop online, which means many people hold an account because of online ordering, not only for points.

About the 3.5 million figure

You will see "3.5 million" in coverage of this story. It is the total membership of More Rewards, attributed to Pattison Food Group. It is not the number of people affected by this incident. The company has not published that number. Treat any headline that equates the two as wrong until the company says otherwise.

How a loyalty data breach like this works, in plain language

A loyalty program is a large customer database with a points ledger attached. Each member has a profile (name, contact details, sometimes a birthday for a birthday offer), a login (a username or email and a password), and a history of transactions and points. Well designed programs keep those in separate places with separate access rules, because each has a different risk.

The More Rewards notice describes an incident that touched the profile store but, by the company's account, not the password store, the card data or the transaction history. The FAQ wording is specific: there is no indication that servers holding More Rewards ID passwords, card data or transaction history were accessed. That reads like a system where credentials and purchase history sit on different servers from basic profile data, which is good practice and is the main reason this breach did not force a password reset.

The fields that were exposed are the ones members fill in to get offers and delivery: mailing address, phone, email, date of birth. Each was optional, going by the company's wording that they were accessed where provided. That has two effects:

1. Exposure varies member by member. Someone who gave only a name and email lost less than someone who filled in every field.
2. Optional fields widen the blast radius. Every optional field a company collects and keeps is a field that can leak. A birthday field that powers a birthday coupon is also, after a breach, one half of a common identity verification check.

Why profile data is still valuable to criminals

No passwords and no card numbers can sound like a near miss. It is not nothing. Contact details plus a date of birth plus a known relationship with a specific grocery brand is the raw material for convincing fraud:

• Brand phishing. An email or text that uses your real name, mentions More Rewards or Save-On-Foods, and says your points are about to expire or that you are owed compensation for the breach. The real relationship makes it believable. Simon Fraser University's Richard Frank told CBC, as reported by The Cool Down, that loyalty programs "usually provide enough details to make realistic scams".
• Breach-themed scams. Fake "credit monitoring enrolment" emails are a predictable follow-up, especially since the company has said real credit monitoring is coming but has not launched it.
• Phone and SIM swap pretexting. A name, address, phone number and date of birth are the kind of details a fraudster may use when impersonating someone to a mobile carrier. The Canadian Anti-Fraud Centre warns that SIM swapping and number porting let fraudsters receive the victim's verification codes and take over email, social media and financial accounts. MITRE ATT&CK catalogues SIM card swap as a mobile technique, T1451.
• Account recovery questions. Birth dates and addresses are still used as knowledge-based checks by some services. Once leaked, they cannot be changed.

Technical details

This incident has no CVE, no published malware sample and no indicators of compromise. The company has not named the access method, and no official advisory with hashes, IP addresses or domains exists. What follows are the concrete, checkable specifics that primary sources do publish, plus the legal mechanics that govern what happens next. Every value below comes from a page we fetched on 24 October 2026.

Disclosure records

Data fields

Wording differences between versions

Defenders reading breach notices should compare versions, because the wording often tightens as investigations progress.

• The member email (as published by Fraser Valley News Network on 16 October and quoted by CTV News) says that, on the information available, no other personal information, for example passwords, card data or transaction history, was accessed.
• The incident page (last updated 23 October) adds that there is no indication that the servers containing More Rewards ID passwords, card data or transaction history were accessed. That is a statement about separate systems, not just about fields.
• Fraser Valley News Network's own summary, above the email text, lists "account passwords" among data that may have been accessed. The company's email, published in the same article, says the opposite. We follow the company's statement and flag the discrepancy.

Official sender domains and their DNS records

The company says official messages come only from @mail-morerewards.ca and @morerewards.ca. We queried their public DNS records on 24 October 2026. These records can change at any time; check again before relying on them.

What this means in practice: both domains publish a DMARC policy that asks receivers to quarantine mail that fails authentication. The pct tag tells receivers what share of failing mail the policy should apply to. A message that fails DMARC for either domain deserves suspicion; a message that passes is from infrastructure the domain owner authorised, but it is still worth checking what it asks you to do. Lookalike domains, such as extra hyphens or different top level domains, are not covered by these records at all, which is why the company's advice to verify through a known channel matters more than any header check.

You can reproduce the lookups yourself:

dig +short TXT _dmarc.morerewards.ca
dig +short TXT _dmarc.mail-morerewards.ca
dig +short TXT morerewards.ca | grep -i spf
dig +short MX mail-morerewards.ca

The reporting framework in Canada

The company says it notified privacy regulators but does not name them. Here is how the rules work for a private company handling customer data in Western Canada. Which law applies depends on the province and on whether data crosses provincial or national borders: Alberta and British Columbia have their own private sector privacy laws, and the federal law, PIPEDA, applies to many interprovincial and international flows. We do not claim any specific filing beyond what the company says.

Two points stand out for defenders and privacy teams:

1. The regulator wants a number. The federal regulations require "the number of individuals affected by the breach or, if unknown, the approximate number". So a company that has not published a count publicly may still have given one, or an estimate, to a regulator. Public silence is not the same as not knowing.
2. RROSH turns on sensitivity and probability of misuse. The Office of the Privacy Commissioner says the assessment weighs how sensitive the information is and how likely it is to be misused. Dates of birth combined with contact details tend to raise both, because they feed identity fraud.

What changed since first reports

What to do now

If you are a More Rewards member

1. Check whether you were notified. Search your inbox, junk and spam for mail from @mail-morerewards.ca or @morerewards.ca sent on or after 16 October. One email arrives for each address on the account.
2. Do not click links in unexpected messages about the breach. If a message mentions More Rewards, points, compensation or credit monitoring, open the More Rewards site or app yourself, or call the number printed on the incident page, instead of using any link or number in the message.
3. Never give out codes. The company says it will never ask for your password, verification codes, card or banking details, SIN or security answers. Anyone asking for those is not the company.
4. Lock down your mobile account. Ask your carrier about a port-out PIN or account passcode. The Canadian Anti-Fraud Centre advises contacting your provider about extra security measures and calling them at once if your phone suddenly loses service.
5. Move important accounts off SMS codes where you can. An authenticator app or a security key is harder to steal through a SIM swap than a text message.
6. Change knowledge-based answers that use your birthday or address. If a bank or utility still uses date of birth or postcode as a security check, ask what stronger options it offers.
7. Wait for the real credit monitoring offer. The company says it is working on it. Enrol only through instructions on morerewards.ca, not through an emailed link you did not expect.
8. Report fraud. The Canadian Anti-Fraud Centre takes reports at 1-888-495-8501 or online.
9. Complain or ask questions. The incident page lists the customer service line and the Pattison Food Group privacy officer contact.

If you run a loyalty, CRM or customer profile platform

This incident has no CVE to patch. The useful work is checking whether your own profile stores look like an attractive single server, and whether you would notice someone reading them. The commands below are for your own systems.

1. Measure how much optional data you actually hold

Before you can minimise data, find out how much of each optional field is filled in. For a PostgreSQL profile table:

SELECT
  count(*)                                   AS members,
  count(date_of_birth)                       AS with_dob,
  count(phone)                               AS with_phone,
  count(mailing_address)                     AS with_address,
  round(100.0 * count(date_of_birth) / NULLIF(count(*), 0), 1) AS pct_dob
FROM loyalty_member_profile;

If a field powers one minor feature (a birthday coupon, say) but is held for millions of people, decide whether you can store month and day only, store an age band, or drop it for inactive members.

2. Find every copy of the profile data

Profile data rarely stays in one table. Look for the same columns in replicas, warehouse tables, marketing exports and test databases:

SELECT table_schema, table_name, column_name
FROM information_schema.columns
WHERE column_name ILIKE ANY (ARRAY['%birth%', '%dob%', '%phone%', '%postal%', '%address%'])
ORDER BY table_schema, table_name;

Run the equivalent in each database and warehouse. Every match is a place a breach notice might have to cover.

3. Make bulk reads visible

A profile store that serves single-member lookups for an app should almost never return hundreds of thousands of rows in one session. In PostgreSQL, log connections, disconnections and slow or large statements so that unusual reads leave a trace:

# postgresql.conf
log_connections = on
log_disconnections = on
log_min_duration_statement = 2000      # log statements over 2 seconds
log_line_prefix = '%m [%p] user=%u db=%d app=%a client=%h '

Then, with the pg_stat_statements extension enabled, look for statements that return far more rows than your application's normal pattern:

SELECT query, calls, rows, rows / NULLIF(calls, 0) AS rows_per_call
FROM pg_stat_statements
ORDER BY rows DESC
LIMIT 20;

For MySQL and MariaDB, enable an audit plugin or the general log on a sample basis, and alert on large SELECT results from accounts that are not your application's service account.

4. Watch what leaves the server

A profile database should talk to your application tier and your backup system, and almost nothing else. On a Linux host, list established outbound connections and the processes behind them:

sudo ss -tnp state established '( dport != :5432 )' | awk 'NR>1 {print $5, $6}' | sort | uniq -c | sort -rn | head

In a cloud network, query flow logs for unusually large transfers from database subnets. For example, with AWS VPC Flow Logs in CloudWatch Logs Insights:

fields @timestamp, srcAddr, dstAddr, dstPort, bytes
| filter srcAddr like /^10\.20\.30\./
| stats sum(bytes) as total by dstAddr, dstPort
| sort total desc
| limit 20

Replace the subnet with your database subnet. Default deny egress for database hosts, with explicit allow lists, turns a quiet copy into a blocked connection and an alert.

5. Check your own sender authentication before you need it

If you ever have to send a breach notice, criminals will send lookalikes the same week. Check now that the domains you send from publish SPF, DKIM and an enforced DMARC policy:

dig +short TXT _dmarc.example.com
dig +short TXT example.com | grep -i spf

Publish your official sender domains in advance, on a page customers can find, so that a breach notice can point to a list that already existed.

6. Separate the stores that matter most

The More Rewards notice suggests passwords, card data and transaction history lived on servers that were not indicated as accessed. Whatever your architecture, test that separation: a credential on the profile server should not be able to read the password store, and a compromise of one host should not expose every category of customer data at once.

What would have helped

This section is about any organisation that runs a similar program. It is not a judgement on More Rewards or Pattison Food Group, whose notice describes same-day shutdown of the affected server, outside investigators and notification within three days.

Practices that shrink the window and the blast radius

Collect less, keep less. Every optional field is a liability as well as a feature. Ask for date of birth only if it powers something members value, and consider month and day without year. Purge optional fields from accounts that have been inactive for years.

Encrypt the sensitive optional fields at the application layer. Disk encryption does not help when an attacker reads through the database engine. Field level encryption for date of birth and phone, with keys held outside the database host, means a raw read of the table returns ciphertext.

Separate profile, credential and transaction stores. The notice suggests this was in place for passwords, card data and history, which is why members did not have to reset passwords. That is worth copying.

Alert on volume, and block quiet exits. A profile service that normally reads one row per request should alert when a session reads thousands, and database hosts should not be able to reach the internet except through explicit allow lists. The commands above show where to start.

Patch what faces the internet and know what you run. We do not know how the intruder reached the server. In general, internet-facing applications and remote access systems are common starting points, so an accurate inventory of what you expose and which software versions it runs is basic hygiene. Our October edge device zero-days roundup covers several examples from this month.

Prepare the customer message before the incident. Publish official sender domains, keep DMARC at enforcement, and have a template FAQ that answers the questions members will ask: do I reset my password, are my points safe, why did I get two emails. The More Rewards FAQ answers those questions clearly and is a good model.

Plan for the count question. Journalists and regulators will ask how many people were affected. Being able to answer quickly depends on knowing, ahead of time, which records each server holds.

Where Safeguard fits

Safeguard is a software supply chain security platform. Be clear about what that does and does not cover for an incident like this.

What Safeguard does not do here. It does not monitor database queries, correlate logins, detect data leaving your network, classify personal data or enforce field level encryption. It is not a SIEM, an EDR, a database activity monitor or a data loss prevention tool. The access method in this case is undisclosed, so we cannot say Safeguard would have prevented anything, and we do not claim it.

What Safeguard does do that is relevant. Many server intrusions start with, or are helped by, known vulnerable software in the applications teams build: an outdated web framework in a member portal, an unpatched library in a loyalty API, an old base image behind an admin tool. That part is in scope.

• Know what you run. safeguard scan --dir . scans a repository, safeguard scan --image <name> scans a container image and safeguard scan --sbom <file> reads an existing SBOM. Results land as JSON under ./output. In the platform, you can see which projects contain a given component and version, which is the question you need answered fast when a new advisory lands.
• Match against vulnerability data, then rank by reachability. Findings are matched against vulnerability databases, and reachability analysis shows which vulnerable code paths your application actually calls, so services that hold customer data get fixed first.
• Stop vulnerable versions shipping. Policies and gates are evaluated in the platform and in CI with safeguard exec, so a portal or API that reads loyalty profiles cannot deploy with a known exploited vulnerability.
• Fix with approval. Autonomous remediation opens fix pull requests and ships switched off by default. The Safeguard CLI's assistant can edit code and run commands with your approval, with /permissions modes Ask, Accept edits, Plan, Auto (the default) and Strict. Desktop and phone apps can send work to a computer running the CLI and approve each command.

None of this replaces data minimisation, field encryption, query monitoring or egress control. It covers the software you build and ship, so that a missing patch is one fewer thing an intruder can use.

Zero-Day Discovery and Gold

Two Safeguard capabilities are aimed at the time before and just after a vulnerability becomes public. They are relevant to the general habit this post argues for, which is shortening the time between "a fix exists" and "the fix is running". Nothing below is about this incident's access method, which is undisclosed.

• Zero-Day Discovery looks for previously unknown flaws before a CVE exists, in two modes: an agentic mode and a deterministic scanner mode. Findings are issued as SGZ advisories before they reach public CVE databases. It covers seven package ecosystems. It does not cover operating systems, appliances or commercial business software, so it would not apply to a closed vendor product running on a loyalty server.
• Gold Open Source at gold.safeguard.sh is free and needs no login. It gives searchable CVE intelligence with CVSS, EPSS, KEV status, affected and fixed versions and a recommended safe version, plus a free read API and a CI gate GitHub Action.
• Gold Registry at registry.safeguard.sh is paid. It provides hardened drop-in components and container images held to zero exploitable critical or high CVEs, with SLSA L3 or higher provenance, Sigstore signatures and evidence pages. An artifact loses its badge if it regresses.

The point is the habit: pull patched, signed components from a curated source and rebuild fast, so the applications in front of your customer data are not the easy step.

Common mistakes after a breach like this

Reading "3.5 million" as the victim count. It is the program's total membership. The affected count is undisclosed.

Assuming no passwords means no risk. Contact details plus date of birth fuel phishing, SIM swap attempts and knowledge-based account recovery.

Trusting a message because it uses your real name. After this breach, criminals may know your name, address and birthday. Personal details in a message prove nothing.

Clicking a credit monitoring link in an unexpected email. The company has said the service is not live yet. Enrol only through morerewards.ca.

For companies: keeping old optional data forever. Fields collected for a promotion years ago are still in scope for a breach today.

For companies: discovering the sender domain problem during the incident. Publish official domains and enforce DMARC long before you need to send a breach notice.

Open questions

• How many members were affected, and what share had a date of birth on file?
• How did the intruder reach the server: a vulnerable application, a stolen credential, a third party, or something else?
• Was data copied out, or only accessed in place?
• Which regulators were notified, and has the federal Privacy Commissioner or a provincial commissioner opened an inquiry?
• When will credit monitoring launch, and for how long?
• What exactly has been strengthened in monitoring and security?

We will update this post if the company or a regulator answers any of these.

FAQ

What happened to More Rewards?

On 13 October 2026, the More Rewards team found unauthorised activity on one of its servers and shut it down that day. On 16 October it confirmed that member names, and where provided addresses, phone numbers, email addresses and dates of birth, were accessed, and it emailed affected members.

Which stores are affected?

More Rewards is the loyalty program for Pattison Food Group grocery banners. Coverage names Save-On-Foods, Buy-Low Foods, PriceSmart Foods, Nesters Market and Quality Foods. The incident affects More Rewards member data, not any one store.

How many people were affected?

The company has not said. More Rewards has more than 3.5 million members in total, according to Pattison Food Group as cited in coverage, but that is the membership size, not the number affected.

Were passwords or credit cards exposed?

The company says no. It says there is no indication the servers holding More Rewards ID passwords, card data or transaction history were accessed, and that no password reset is required.

Are my More Rewards points safe?

The company's FAQ says yes: all accounts are secure and points are not at risk.

I did not get an email. Am I affected?

The company says it emailed every affected customer at each address on the account. Check junk and spam. If you still have concerns, call the number on the incident page.

How do I know an email is really from More Rewards?

The company says official emails come only from @mail-morerewards.ca and @morerewards.ca, and it will never ask for passwords, codes, card or banking details, SIN or security answers. Even so, verify through a channel you already know rather than links in the message.

Will there be credit monitoring?

The company says it is working to offer credit monitoring to members who want it and will post an update on its incident page.

Who has been told?

The company says it notified the appropriate authorities and privacy regulators. It has not named them. Under federal law, breaches with a real risk of significant harm must be reported to the Privacy Commissioner of Canada, and Alberta has its own reporting duty to its commissioner.

Could Safeguard have prevented this?

We cannot say that, and we do not claim it. The access method is unknown, and Safeguard does not monitor databases or network traffic. Safeguard helps teams find and fix known vulnerable components in the software and container images they build and ship, which narrows one common route into servers.

Related reading

• October 2026 security incidents: what would have helped
• Capcom ID breach: what is confirmed
• Burger King Japan data breach: what to know
• IDCF Cloud ransomware and third party risk
• SBOM incident response: finding affected products fast

Fix it without waiting for upstream

This incident's access method is undisclosed and may not involve open source at all. Where the member portals, APIs and images in front of customer profile data do carry known vulnerable components, these are the ways to close the gap quickly.

Whatever the vulnerability, most of the risk sits in two gaps. The first is the time between a fix being published and that fix actually running in your production builds. The second, and worse, is the time before any fix exists at all, while a maintainer works out a patch and a release schedule. Waiting through both gaps is a habit, not a requirement. Safeguard gives teams three ways to close them.

1. Autonomous remediation: pull requests, not tickets

When a fixed version exists, Safeguard's Griffin models open a tested, policy gated pull request that moves the affected dependency to the safe version. You can run it on one repository or in bulk across every project that carries the vulnerable version. Remediation covers eight categories, including dependencies, licenses, security posture and findings. Reachability analysis ranks the vulnerable code paths your application actually calls first, so the first pull requests you merge are the ones that matter most. Autonomous remediation ships switched off, with every category set to Manual, so your team decides how much runs on its own and what still needs a human approval.

2. Gold Open Source: the safe version in seconds, free

gold.safeguard.sh is free and needs no login. Search any CVE or package to see affected and fixed versions, CVSS, EPSS, CISA KEV status and a recommended safe version, or use the "Am I affected?" checker. The same data is available through a free read API, README status badges and RSS threat feeds. The safeguard-sh/gold-scan-action GitHub Action can fail a build on a known exploited vulnerability, on any known vulnerability, or never, so a version you have just removed cannot quietly come back in next week's merge.

3. Gold Registry: start from components that are already fixed

registry.safeguard.sh provides hardened, drop in replacements for upstream packages and container images. Every Gold artifact is held continuously to zero exploitable critical or high CVEs, zero malware and a completed license check, with SLSA L3 or higher provenance, a Sigstore signature and a public evidence page you can hand to an auditor. An artifact loses its Gold badge if it regresses. Teams can point their own package directory at the registry so hardened equivalents resolve without changing how developers install anything.

When upstream has no fix yet, or will not ship one, Safeguard first works to get the fix accepted upstream. If the issue is severe or upstream will not move, Safeguard builds a fork, fixes the vulnerability there and publishes a hardened Gold build, so you are not stuck on a maintainer's release schedule. You can also request a hardened, compatibility tested build of a specific package. This fork and patch flow is in early access today, so ask which packages it covers before you plan around it.

One honest limit: when the vulnerable code lives in a vendor appliance, a hosted service or an operating system runtime you do not build yourself, the fix still has to come from that vendor or distribution. The steps above apply to the open source dependencies and container images you build and ship, which is where most teams carry the largest and least tracked share of their exposure.

See how Safeguard would have helped

These are real product sessions on other examples. None of them shows this incident, More Rewards systems, or a database intrusion.

The CLI demo shows the assistant fixing a lodash CVE: it reads the finding and advisory, asks before each command, edits package.json to lodash 4.17.21, runs npm install and npm test with your approval, and pushes nothing. For a loyalty platform, you would run the same scan against the repository behind a member portal or points API and ask the assistant to move a vulnerable dependency to its fixed version. It asks before each command.

Click through it at your own pace, or open it full screen.

The desktop app demo shows a CLI session in the conversation list, a request for work on the computer, a folder choice, and Approve or Deny on each command and file edit, ending with the upgrade done and tests passing. When a team is hardening services that read customer profiles during an incident, that per-step approval keeps a human in charge of every change.

Click through it at your own pace, or open it full screen.

The mobile demo is a real Android session: it sends work to a computer running the CLI and approves the command on the phone with Allow once, Allow for turn or Deny. In this case the company confirmed affected accounts and notified members on a Friday evening. The same flow lets an on-call engineer approve an upgrade or a rebuild from a phone outside office hours.

Click through it at your own pace, or open it full screen.

To try it on your own code, download Safeguard and follow the CLI docs.

Quick check

Sources

• More Rewards: incident update and FAQ (last updated 23 Oct 2026) (primary)
• More Rewards home page, linking the incident update (primary)
• Pattison Food Group: company overview (primary)
• Justice Laws Website: PIPEDA, section 10.1, breaches of security safeguards (primary)
• Justice Laws Website: Breach of Security Safeguards Regulations, SOR/2018-64 (primary)
• Office of the Privacy Commissioner of Canada: What you need to know about mandatory reporting of breaches of security safeguards (primary)
• Office of the Privacy Commissioner of Canada: Report a privacy breach at your organization (primary)
• Alberta King's Printer: Personal Information Protection Act, SA 2003, c P-6.5 (primary)
• Office of the Information and Privacy Commissioner for BC: resources for private organizations (primary)
• Canadian Anti-Fraud Centre bulletin on SIM swap scams, via the New Brunswick Financial and Consumer Services Commission (primary)
• MITRE ATT&CK T1451: SIM Card Swap
• MITRE ATT&CK T1566: Phishing
• MITRE ATT&CK T1213: Data from Information Repositories
• NIST SP 800-122: Guide to Protecting the Confidentiality of Personally Identifiable Information
• PostgreSQL documentation: error reporting and logging
• CTV News: More Rewards customers' data accessed in a cybersecurity breach (17 Oct 2026)
• CP24: More Rewards customers' data accessed in a cybersecurity breach (17 Oct 2026)
• BNN Bloomberg: More Rewards customers' data accessed in a cybersecurity breach (17 Oct 2026)
• Fraser Valley News Network: More Rewards program cyber hack, customer info compromised (16 Oct 2026)
• iPhone in Canada: More Rewards data breach, what Save-On-Foods shoppers should do now (18 Oct 2026)
• The Cool Down: Canadian supermarket chain says cybersecurity breach exposed customer data (cites CBC News)

Last reviewed: 24 October 2026. This is a developing story; check the linked advisories for the latest status.