Data Privacy Weekly: Your Industry News Series

Data Privacy Weekly is Encryption Consulting’s recurring roundup of the data-privacy and security stories that mattered that week. This edition covers two new AWS encryption services (dual-layer S3 encryption and Payment Cryptography), the iOttie Magecart card-skimming breach, UPS’s SMS-phishing data breach, and Microsoft’s nOAuth Azure AD flaw. The one action to prioritize: confirm your payment and identity integrations don’t quietly rely on the exact misconfigurations these stories describe.

Key Takeaways

• AWS launched DSSE-KMS, dual-layer S3 encryption with keys in AWS KMS, meeting FIPS and CNSA encryption requirements for organizations that need defense-in-depth beyond S3’s default single-layer encryption.
• AWS also launched Payment Cryptography, a managed alternative to on-premises payment HSMs, aimed at fintechs and processors that need PCI-relevant key management without owning physical hardware.
• Mobile-accessory maker iOttie disclosed a nearly two-month Magecart card-skimming breach; malicious JavaScript on the checkout page captured card and personal details directly from shoppers.
• UPS disclosed that personal data exposed through its Canadian package-lookup tool between February 2022 and April 2023 was used to run SMS-phishing campaigns impersonating UPS and other brands.
• Microsoft fixed nOAuth, an Azure AD (Entra ID) OAuth misconfiguration risk that could let an attacker take over an account by matching the email claim on their own account to a victim’s.

What Is Data Privacy Weekly, and Why Does This Edition Matter?

Data Privacy Weekly is a curated recap of the week’s most consequential data-privacy, encryption, and security-incident news, each item paired with a plain-language note on what it means for enterprise security teams. Stories are selected from named primary reporting and vendor advisories at the time of original publication (June 2023); this edition was reviewed in September 2026, with facts checked against current vendor documentation where the underlying service or vulnerability status could have changed.

This week pairs two legitimate encryption product launches with two breaches that succeeded despite encryption being present elsewhere in the stack, a useful reminder that encrypting data at rest doesn’t protect against client-side skimming, phished credentials, or an identity-provider logic flaw.

This Week’s Data Privacy and Security Headlines

01. AWS Unveils DSSE-KMS, A Dual-Layer Encryption for Enhanced Data Security

What happened: AWS introduced Amazon S3 dual-layer server-side encryption with keys stored in AWS Key Management Service (DSSE-KMS), applying two independent layers of encryption to objects uploaded to an S3 bucket. DSSE-KMS is designed to meet FIPS and CNSA encryption requirements and joins S3’s existing server-side encryption options. It’s available across all AWS Regions and can be enabled via the AWS CLI, Management Console, or the S3 REST API.

Why this matters for enterprises: Regulated industries (defense, government contractors, some financial services) increasingly need to demonstrate defense-in-depth encryption, not just a single AES-256 layer, to satisfy compliance mandates. DSSE-KMS gives AWS-native teams a way to meet that bar without building custom double-encryption pipelines, but the keys still need the same lifecycle discipline (rotation, access control, audit logging) as any other KMS-managed key.

02. Streamlined Payment Security: AWS Introduces Payment Cryptography for Effortless Transactions

What happened: At its re:Inforce conference, AWS launched Payment Cryptography, a managed service that performs the encryption and decryption operations payment processors traditionally ran on on-premises, PCI-compliant HSMs. It supports symmetric and asymmetric keys (TDES, AES, RSA) with key separation and access control, priced per API call and per active key, launching in the US East and US West regions.

Why this matters for enterprises: This lowers the capital and operational barrier to PCI-relevant cryptography for early-stage fintechs and payment facilitators, but it doesn’t remove the need for proper key governance, separation of duties, and audit trails; those requirements move from a hardware appliance you own to a managed service you must configure and monitor correctly.

03. iOttie Site Hacked: Customer Credit Cards Stolen in Major Data Breach

What happened: Mobile-accessory maker iOttie disclosed a nearly two-month Magecart-style breach: malicious scripts injected into its website between April 12 and June 2 captured shoppers’ credit card numbers and personal information directly from the checkout page as customers typed them in. The malicious code has since been removed, and the company advised affected customers to watch statements for fraud.

Why this matters for enterprises: Magecart attacks operate client-side, in the browser, which means server-side encryption at rest does nothing to stop them. E-commerce teams need script integrity monitoring (subresource integrity, content security policy) and payment tokenization so raw card numbers never touch first-party checkout code in the first place.

04. UPS Data Breach Exposes Customers to SMS Phishing Attacks

What happened: UPS disclosed that personal data obtained through its Canadian online package-lookup tool between February 2022 and April 2023 was later used to run SMS-phishing campaigns, some impersonating other brands such as LEGO and Apple, against affected customers. UPS restricted access to the exposed lookup data and began notifying affected individuals while working with law enforcement.

Why this matters for enterprises: A publicly reachable lookup tool that returns contact details, even without a full account breach, is enough raw material for a convincing phishing campaign. Any customer-facing tool that returns PII in response to a simple query (order number, tracking number) deserves the same rate-limiting and data-minimization scrutiny as a login form.

05. Microsoft Addresses Azure AD Authentication Vulnerability

What happened: Microsoft fixed nOAuth, a misconfiguration risk in Azure AD (now Microsoft Entra ID) OAuth applications. Because some apps trusted the unverified email claim in an access token, an attacker could change the email on their own Azure AD admin account to match a victim’s email, then use “Log in with Microsoft” to fully take over the victim’s account in the vulnerable application.

Why this matters for enterprises: This was an application-logic flaw, not a flaw in Azure AD itself, which means any organization building or integrating OAuth-based “Login with Microsoft” flows needs to independently verify Microsoft’s guidance is followed: never trust an unverified email claim as a unique identifier, and validate against the immutable object ID instead.

Story-to-Action Decision Table

How to Turn This Week’s Headlines Into Action

1. Map each story to your own exposure. Identify which of these apply to you: S3 or cloud storage needing defense-in-depth encryption, payment processing infrastructure, public-facing lookup tools that return PII, and any “Login with Microsoft” or similar OAuth integration.
2. Check current control coverage. Confirm whether encryption-at-rest, script integrity monitoring, rate limiting, and OAuth claim validation are actually implemented, not just assumed.
3. Prioritize by likelihood and impact. An unpatched OAuth identity flaw or an unmonitored checkout page usually outranks a compliance nice-to-have like an extra encryption layer.
4. Assign an owner and a deadline. Give each gap a named owner, whether that’s a cloud engineer, an e-commerce lead, or an identity architect.
5. Verify the fix. Re-test the checkout page for injected scripts, re-review the OAuth claim logic, and confirm key access logs are actually being reviewed, not just generated.

Encryption Consulting’s Take

Two of this week’s stories are AWS shipping genuinely useful managed cryptography (DSSE-KMS, Payment Cryptography), and two are breaches that succeeded in spite of encryption existing somewhere in the stack. That pairing is the real lesson: encryption at rest, in a KMS, or inside a payment HSM does not protect a checkout page’s client-side JavaScript, and it does not validate an OAuth email claim correctly. Cryptography is necessary but not sufficient; it has to be paired with the surrounding application logic, monitoring, and key governance that actually determines whether an attacker can bypass it.

Limitations of This Roundup

This edition reflects public reporting and vendor documentation available at the time each story was originally covered (June 2023), reviewed in September 2026. Service names, pricing, and regional availability for AWS services referenced here may have changed since original publication; always confirm current details against AWS’s own documentation before making an architecture decision. This roundup is informational, not legal, compliance, or incident-response advice.

Key Terms in This Edition

• DSSE-KMS: Amazon S3 dual-layer server-side encryption with keys managed in AWS KMS.
• HSM (hardware security module): a dedicated, tamper-resistant device that generates, stores, and uses cryptographic keys.
• PCI DSS: the Payment Card Industry Data Security Standard governing how payment card data must be protected.
• Magecart: a family of client-side, JavaScript-based credit-card-skimming attacks against e-commerce checkout pages.
• OAuth: an authorization framework used to let one application access resources on behalf of a user without sharing a password.
• nOAuth: a class of Azure AD/Entra ID application misconfiguration where an unverified email claim is trusted as a unique user identifier.

Frequently Asked Questions

What is DSSE-KMS, and is it different from regular S3 encryption?
DSSE-KMS is Amazon S3 dual-layer server-side encryption with keys stored in AWS KMS. It applies two independent layers of encryption to the same object, which is intended to meet regulatory and compliance mandates that require defense-in-depth encryption, beyond the single-layer AES-256 encryption S3 already applies by default.

Does AWS Payment Cryptography replace an on-premises payment HSM?
For many payment facilitators and processors, yes. AWS Payment Cryptography provides PCI-relevant encryption and decryption for payment data using AWS-managed, compliant HSMs, which lets smaller fintechs avoid owning and operating physical payment HSMs, though larger institutions with existing HSM investments and specific certification requirements may still run hybrid setups.

What was the nOAuth flaw in Azure AD, and is it fixed?
nOAuth was a misconfiguration risk in Azure AD (now Microsoft Entra ID) OAuth applications that let an attacker take over an account by changing the email claim on their own account to match a victim’s email, then using Log in with Microsoft. Microsoft deployed mitigations and has advised developers to review their applications’ authorization logic; the underlying risk is a configuration issue in how an application trusts the email claim, so newly built or poorly configured apps can still be exposed if developers don’t follow Microsoft’s guidance.

What is a Magecart attack, like the one that hit iOttie?
Magecart refers to a family of digital credit-card-skimming attacks where malicious JavaScript is injected into an e-commerce checkout page, capturing card details as customers type them in. It’s a client-side attack that standard server-side encryption doesn’t stop, which is why payment tokenization and script integrity monitoring matter alongside encryption.

How Encryption Consulting Can Help

This week’s stories span cloud key management, payment cryptography, and identity. HSM-as-a-Service gives you FIPS-140-validated, hardware-backed key protection for exactly the kind of defense-in-depth and payment-cryptography use cases AWS’s new services target, without locking you to a single cloud provider. For the certificate-backed identity side of the Azure AD story, CertSecure Manager and PKI-as-a-Service support certificate-based authentication as a stronger alternative to claim-based OAuth trust in high-assurance scenarios.

Talk to an expert about HSM-as-a-Service, or see CertSecure Manager and PKI-as-a-Service in action.

Conclusion

AWS shipped two solid encryption services this week, and two breaches happened anyway, not because encryption failed, but because the attacks targeted layers encryption doesn’t cover: client-side scripts, public lookup tools, and OAuth trust logic. Treat new managed-cryptography services as one input to a broader control set, not a substitute for application-level scrutiny.

Continue the series with the next edition, or go back to the previous edition of Data Privacy Weekly.