Maersk data extraction from a legacy acquired system: what it teaches about M&A security on day one

Short answer. On 11 November 2026, A.P. Moller-Maersk said it had identified "an IT security incident involving unauthorised access and data extraction from one of our local legacy systems from a previous acquisition" (Maersk). The company said its findings "strongly suggest no sensitive data has been disclosed", that the incident "is isolated to a local system", and that it does not anticipate disruption to operations for customers. Maersk did not name the system, the data involved or the date of the intrusion.

A data extortion group calling itself WhiteArmor claims to have taken about 100 GB from what it calls the "OCF/LF Logistics" platform, and has set a 30-day deadline for payment. Maersk bought LF Logistics from the Li & Fung group in a deal that closed on 31 August 2022. Maersk has not confirmed that the affected system came from that acquisition, and nothing the group says has been independently verified.

Whichever acquisition it turns out to be, the lesson for every buyer of companies is the same. The systems you inherit are yours from the day the deal closes, including the ones nobody has had time to integrate, patch or switch off. This post sets out what Maersk confirmed, what the attackers claim, why acquired estates are such a reliable soft edge, and a practical plan to inventory, SBOM, scan and remediate an acquired estate in weeks rather than years.

At a glance

What Maersk actually disclosed

Maersk's short advisory of 11 November 2026, titled "IT security incident", is the only first-party statement so far. Six statements in it matter.

1. The event. Maersk "has identified an IT security incident involving unauthorised access and data extraction from one of our local legacy systems from a previous acquisition." Note the words. This is not a statement that data may have been viewed. It says data was extracted.
2. The response. "Once the Maersk Cyber Security team discovered the issue, a full investigation was immediately launched and remains ongoing, with swift action being taken to secure the affected system."
3. The sensitivity judgement. "Our findings so far strongly suggest no sensitive data has been disclosed." The phrase "so far" is an honest qualifier. It is a point-in-time assessment, and Maersk does not define what it counts as sensitive.
4. The boundary. "The incident is isolated to a local system, and we have found no indication that there has been any impact on other Maersk systems or customer and partner systems that connect to Maersk through integrations such as APIs and EDI." For a logistics company, the API and EDI line is the one partners care most about, because that is how bookings, shipping instructions and advance shipping notices flow between companies.
5. Operations. "We do not anticipate disruption to operations for customers at this time, and customers can continue to use Maersk platforms to book and manage their shipments as usual."
6. A fraud warning. "Please treat any unexpected communications claiming to relate to this matter with caution and verify them through your usual Maersk contact." That line matters more than it looks. Any breach at a logistics company is followed by phishing that uses real shipment details.

The notice also says Maersk will update customers "if we identify any need to inform impacted parties of any further findings."

What the notice does not say is just as useful. It does not name the acquisition, the system, the type of data, how the attacker got in, when it happened or how long the attacker had access. BleepingComputer and Security Affairs both note that Maersk did not share those details, and BleepingComputer said Maersk had not answered its questions at the time of publication. The Register reported the same statement and added no further detail from the company.

What WhiteArmor claims

Everything in this section is a claim by the group trying to extort Maersk, as reported by the press. We have not seen any of the data, and Maersk has not confirmed any of it. We are deliberately not repeating the group's ransom figure.

• Timing of the claim. The group added Maersk to its data leak site over the weekend before Maersk's notice. ISMG reports it took responsibility on Saturday, which was 7 November 2026.
• Source system. About 100 GB from what the group calls the "OCF/LF Logistics" platform, which BleepingComputer describes as a logistics and supply chain platform.
• Data types. According to BleepingComputer and Security Affairs, the group lists nearly 30,000 driver records, passwords stored in plain text, 33 accounts with a "SUPER_ADMIN" role, signed delivery receipts, inventory records with purchase orders and advance shipping notices, and 27,842 mobile device logs containing phone numbers, email addresses and IMEI device identifiers. ISMG's summary adds staff accounts and delivery recipients' names and addresses.
• Deadline. The leak site gives Maersk 30 days to make contact and pay. When Ingeniøren checked on Monday morning, 9 November, a countdown showed 27 days, 15 hours and 28 minutes, pointing to publication on 7 December.
• Framing. The leak site addresses Maersk directly: "Your contract-logistics arm, the former LF Logistics, runs fulfilment for many of the world's largest consumer brands."
• Negotiation. The group told ISMG that Maersk had not contacted it.

Who is WhiteArmor? ISMG describes it as a newly emerged data extortion and ransomware group, active since 21 October 2026, that has claimed attacks on more than 20 organisations, including logistics companies. Ingeniøren called it relatively unknown. A group that is three weeks old has every reason to make its first big name look as large as possible, so treat the volume and the record counts with care until Maersk or an independent analysis confirms them.

What the LF Logistics link rests on

Maersk's notice says "a previous acquisition". The link to LF Logistics comes from two places: the attackers' own leak site, which names "the former LF Logistics", and press analysis. Security Affairs and BleepingComputer both point out that Maersk acquired LF Logistics, the original developer of the platform the group names. Security Affairs adds that Maersk has not confirmed the connection, and BleepingComputer notes that Maersk did not share details of the affected system. Cybernews reported that its research team investigated the claims and concluded the breach is related to LF Logistics, and that it had asked Maersk to comment.

So the honest position today is this. It is plausible, it is widely reported, and it is unconfirmed by the company. Maersk has made other acquisitions, and we won't treat the attacker's label as fact.

The LF Logistics deal is still a good illustration of how big an inherited estate can be. From Maersk's own announcements:

• The target. LF Logistics was a Hong Kong-based contract logistics company, owned 78.3% by Li & Fung and 21.7% by Temasek, founded in 1999 and "run as a standalone company separate from Li & Fung" (Maersk, December 2021).
• The footprint. 10,000 employees and 223 warehouses and fulfilment centres in 14 countries, totalling 2.7 million square metres. The business specialised in B2B and B2C distribution for retail, wholesale and e-commerce.
• The deal. An enterprise value of US$3.6 billion, announced in December 2021 and completed on 31 August 2022, when Maersk said "LF Logistics will be rebranded to Maersk" (Maersk, 31 August 2022).
• The integration. On 3 April 2023 Maersk announced it was "furthering the integration of LF Logistics and Fung Omni into Maersk." The brands moved to Maersk's visual identity and the lflogistics.com and fungomni.com websites redirected to maersk.com. But the notice also said "the legal entities of LF Logistics and Fung Omni remain in place until further notice", with invoicing still controlled by those entities (Maersk, 3 April 2023).

That last point is the one security teams should sit with. A rebrand changes the logo, the website and the email signature. It doesn't change the warehouse management system, the driver app, the proof-of-delivery service or the database behind them. Those keep running, often on their original stack, under their original admin accounts, for as long as the business needs them. Brand integration in months, system integration in years: that is normal, and it is exactly the window in which a "local legacy system" lives.

What nobody knows yet

Here is what remains open, according to Maersk's notice and the outlets that covered it.

• Which acquisition and which system. Maersk has not said. The attackers say OCF/LF Logistics.
• How the attacker got in. No entry point has been reported. Not a vulnerability, not a credential, not a supplier.
• When. Neither the date of the intrusion nor how long access lasted has been disclosed.
• What Maersk counts as sensitive. Its finding that "no sensitive data has been disclosed" may sit alongside the attackers' list of driver records, device logs and delivery receipts. Both statements could be partly true, depending on definitions.
• Whether the claimed data is current. A legacy system can hold years of records. Some of the claimed data may be old.
• Which countries' people are in it. LF Logistics operated across 14 countries in the Asia-Pacific region. Which jurisdictions the claimed driver and recipient records come from has not been reported.

If you are a customer, a driver, a carrier or a consignee who dealt with the former LF Logistics, the practical answer is the same either way: assume shipment details and contact information could be used in convincing phishing, and verify every unexpected request through a contact you already know.

Timeline

Why acquired systems are the soft edge

Maersk knows more about rebuilding after a cyber incident than most companies on earth. In 2017 the NotPetya wiper took its network down, and its then chair later described rebuilding 4,000 servers, 45,000 PCs and 2,500 applications in ten days (The Register). A company with that history invests heavily in its core estate. And still, the incident it disclosed this week sits in a corner of the estate it did not build.

That is the pattern, not the exception. Acquired systems are hard to secure for reasons that have little to do with how good the acquirer's security team is.

They arrive without an owner on your side. The people who built and ran the system often leave in the first year. The ones who stay report into a business unit, not into security. A system with no named owner gets no patch window.

They are kept running on purpose. The acquired business has customers, contracts and live operations. Switching off the warehouse system or the driver app on day one would stop the revenue the acquirer paid for. So the system keeps running, usually "until migration", and migration dates slip.

They live outside your controls. Separate identity directories, separate admin accounts, separate cloud accounts, separate logging, separate vulnerability scanning, or none. Your single sign-on, your endpoint agent and your log pipeline stop at the edge of the old network.

They carry old design choices. Systems built ten or fifteen years ago may store passwords in ways no modern system would, use shared administrator accounts, expose admin consoles to the internet, or run on frameworks that no longer receive security fixes. The attackers' claim of passwords stored in plain text and 33 super-admin accounts, if accurate, would fit that profile exactly.

They hold data longer than anyone remembers. Driver records, device logs and signed delivery receipts accumulate for years. Nobody applied the acquirer's retention schedule because nobody mapped the data in the first place.

They are trusted by partners. Old EDI links, API keys handed to carriers and customers, SFTP drops for advance shipping notices. Maersk's notice specifically says it found no indication of impact on systems connected through APIs and EDI, which tells you how central that question is.

They are a different attack surface from the parent. An attacker who looks at a large group sees a hardened core and a ring of subsidiaries, acquired brands and regional systems. Domains that still resolve, old login pages that still answer, mobile apps still in app stores under the former brand. The ring is cheaper to attack.

The precedent every acquirer should know

The clearest public record of what happens when an acquired system is breached is the UK Information Commissioner's penalty notice against Marriott, dated 30 October 2020 (ICO penalty notice).

The facts, as the ICO sets them out:

• Starwood's IT systems were compromised in 2014. The attacker installed a web shell on a Starwood device on 29 July 2014.
• Marriott acquired Starwood in September 2016. The two networks "were kept separate", with a plan to integrate aspects of the Starwood network over 18 months.
• Marriott "did not detect the Attack at any time between acquiring Starwood and September 2018". During that period the attacker continued to move through the Starwood systems and reached the cardholder data environment.
• Marriott's estimate was that 339 million guest records were affected.
• The ICO fined Marriott £18.4 million under the GDPR.

Two passages from the notice should be on every corporate development team's wall. First, Marriott said that during the acquisition "it was only able to carry out limited due diligence on the Starwood data processing systems and databases". The ICO did not decide whether deeper diligence was possible before the deal, and accepted that in-depth diligence on a competitor may not be possible during a takeover. Second, and more important, the ICO said that while an acquisition is a trigger for due diligence, "the need for a controller to conduct due diligence in respect of its data operations is not time-limited or a 'one-off' requirement."

In plain terms: limited diligence before signing is understandable. Not finishing it after closing is the problem. Once you own the system, you own the duty to secure it, whether or not it carries your logo yet.

What the claimed data says about where to look

We don't know what the attacker took. But if the group's list is even partly accurate, it describes the kind of systems that sit in almost every acquired logistics or field-service business. Treat this as a map for your own estate, not a theory about Maersk's.

The bottom three rows are the ones that turn a data exposure into a full compromise. A legacy application that keeps its own user table, stores passwords badly and has dozens of top-level admins can be taken over completely with a single leaked or guessed password. Fixing those three things is cheap compared to almost anything else on this list.

M&A inherited IT is in scope on day one: a practical plan

Most acquisition security programmes are written as integration plans. They assume the target's systems will soon be replaced, so they focus on connecting networks and migrating users. That leaves a gap of months or years in which the old estate runs outside every control. A better approach treats the acquired estate as in scope for your security programme from the moment the deal closes, with its own inventory, its own scanning and its own remediation queue, whether or not integration has started.

Here is a phased plan that works for most deals. Adjust the timings to the size of the target.

Phase 0: before signing

Diligence access is limited, and that's fine. Use it to size the problem, not to solve it.

• Ask for the inventory they have. Applications, cloud accounts, domains, internet-facing services, identity providers, mobile apps, outsourced IT providers and major software vendors. Ask what they can't list, too.
• Ask for evidence, not questionnaires. Recent penetration test summaries, the last vulnerability scan of internet-facing assets, independent assurance reports such as SOC 2 Type II or ISO/IEC 27001 certificates, and incident history for the last three years.
• Ask for SBOMs of the software they build. If the target ships software or runs significant in-house applications, a software bill of materials in SPDX or CycloneDX format for each one tells you more about technical debt than any questionnaire.
• Look from the outside. You can see a lot without access: domains and subdomains from DNS and Certificate Transparency logs, exposed login pages, mobile apps in public app stores, public code repositories and known breach history. None of this needs the target's permission.
• Write security into the deal. Talk to counsel about representations on known incidents, specific indemnities for pre-closing breaches, and a security schedule in any transitional services agreement. This is general information, not legal advice.

Phase 1: signing to close

• Name an owner. Before day one, decide who on the acquirer's security team owns the acquired estate. One person, with a deputy.
• Agree a day-one access plan. Read-only access to the target's cloud accounts, identity directories, firewalls and logging is what you need first. Negotiate it now so you don't lose two weeks after closing.
• Prepare the notices. If an incident surfaces at closing, you will need regulator, customer and employee notices quickly. Draft templates in advance.

Phase 2: day one to day 30

This is where most of the risk reduction happens. The goal is to know what you own, cut the easiest paths in, and start seeing activity.

Build the real inventory. Merge every source you can get, because no single one is complete:

• the target's own asset lists and configuration database, however out of date;
• every cloud account, subscription and project, with owners;
• DNS zones, registrar accounts and Certificate Transparency logs for every domain, including former brands;
• IP ranges registered to the target's legal entities;
• source code hosts and build systems;
• container registries and artifact repositories;
• mobile apps published under the target's developer accounts;
• identity providers and every application that authenticates against them, plus the applications that don't;
• finance records of recurring software and hosting payments, which catch systems nobody listed;
• EDI and API partner lists, with the credentials each partner holds.

Tag every asset with an owner, a business purpose, the data it holds and a planned end state: keep, migrate or retire, with a date.

Fix identity first. Identity is where the cheapest, biggest wins are.

• Require multi-factor authentication on every administrative path into the acquired estate: cloud consoles, VPNs, remote access tools and application admin panels.
• List every top-level admin account in every application. Remove the ones that are shared, unowned or belong to people who have left. A legacy app with more than a handful of super admins has a problem worth fixing this week.
• Reset credentials for privileged and service accounts, and rotate API keys and tokens shared with partners and vendors.
• Bring the acquired applications behind the acquirer's single sign-on where they support it. Where they don't, put them behind an authenticating proxy or VPN so the login page is not on the open internet.

Shrink the exposed surface. Every admin console, test instance and forgotten login page that answers from the internet is an invitation. Close what nobody can justify, restrict the rest by network, and record each exception with an expiry date.

Start collecting logs. Forward authentication logs, admin actions and bulk export events from acquired systems into the acquirer's monitoring on day one, even before anything else is integrated. Detection that stops at the edge of the old network is the Marriott failure mode.

Segment. Treat the acquired network as untrusted until proven otherwise. Allow only the specific connections the business needs between it and the parent, and log them. Maersk's line that partner APIs and EDI were unaffected is the outcome you want to be able to state with evidence.

Phase 3: day 30 to day 90

Now go deeper, system by system, starting with what is exposed and what holds the most sensitive data.

Generate SBOMs for everything you can build. For in-house applications, generate an SBOM from source at build time, so it reflects what actually ships. For containers, generate one per image digest. For packaged vendor software, ask the vendor for its SBOM. The NTIA's minimum elements for an SBOM, published in July 2021, are a sensible floor: supplier, component name, version, other unique identifiers, dependency relationships, the author of the SBOM data and a timestamp. SPDX is published as ISO/IEC 5962:2021, and CycloneDX is maintained by OWASP and standardised by Ecma International, so either format will be readable by tools on both sides of the deal.

Scan in layers. Each layer finds different problems:

• Software composition analysis on every SBOM, to find known vulnerable open-source components, prioritised by whether they are on the CISA KEV catalogue, by EPSS score and by whether the vulnerable code is reachable.
• Static analysis of first-party code, which is where weaknesses such as plain-text password storage, missing authorisation checks and injection flaws show up.
• Dynamic testing of the web applications and APIs you have verified you own, especially login flows, admin panels and the APIs that mobile apps call.
• Cloud posture checks on every inherited cloud account, and configuration checks on Kubernetes clusters and infrastructure-as-code templates.
• Database posture checks: transport encryption, authentication rules, grants, audit logging and encryption at rest.
• Mobile app review for the apps drivers and field staff use, including how they authenticate to the back end.
• Network and device scanning for on-premises sites such as warehouses, which often run older operating systems and directory services.

Prioritise by exposure and data. A medium-severity flaw on an internet-facing system that holds driver identities matters more than a critical flaw on an isolated test box. Rank by reachability from the internet, data sensitivity and exploitation evidence, in that order.

Fix password storage properly. If any acquired application stores passwords in plain text or with an outdated hash, fix it in code, not in policy. The OWASP Password Storage Cheat Sheet recommends Argon2id, with a minimum of 19 MiB of memory, an iteration count of 2 and one degree of parallelism. Where Argon2id is not available it recommends scrypt, and bcrypt only for legacy systems where neither is available. Where passwords are stored in plain text, you can hash every stored value immediately, because you already have the input. Then force a reset for every account, because a plain-text store has to be treated as exposed.

Map the data and cut what you don't need. Driver records, device logs and delivery receipts from five years ago are liability, not assets. Apply the acquirer's retention schedule to the acquired systems, archive what the law requires, and delete the rest.

Bring the vendors into your programme. Every acquired business comes with its own suppliers: the company hosting its warehouse system, the developer of its driver app, its EDI provider. Add them to your third-party risk register, ask for SBOMs and assurance reports, and add breach-notification clauses where contracts allow.

Phase 4: day 90 to decommission

• Keep a dated retirement plan. Every legacy system gets a migration or switch-off date and a named owner. Review slips monthly at a level that can say no.
• Keep scanning until it's gone. A system scheduled for retirement next year still needs patching this month. Retirement plans are not compensating controls.
• Retire cleanly. When a system is switched off, remove its DNS records, revoke its certificates, close its firewall rules, delete its cloud resources, revoke the partner credentials it issued and archive or delete its data. Old hostnames that still resolve and old API keys that still work are how "retired" systems get breached.

The regulatory angle

This section is general information, not legal advice. Talk to counsel about your own obligations.

GDPR, where it applies

If an acquired system holds data about people in the European Union, or the controller is established there, the GDPR (Regulation (EU) 2016/679) applies to it like any other system. Article 32 requires security appropriate to the risk. Article 33 requires the controller to notify the supervisory authority without undue delay and, where feasible, within 72 hours of becoming aware of a breach, unless it is unlikely to result in a risk to people. Article 34 requires telling individuals directly where the risk is high. The Marriott notice shows that a regulator will look at what the acquirer did with an inherited system after the regulation applied to it, not only at what the seller did before.

NIS2 for transport and logistics

The EU's NIS2 Directive (Directive (EU) 2022/2555) lists transport, including water transport, among its sectors of high criticality. For entities in scope, Article 23 sets a staged reporting model for significant incidents: an early warning within 24 hours of becoming aware, an incident notification within 72 hours, and a final report no later than one month after the incident notification. Article 21 requires risk management measures that include supply chain security and the security of network and information systems acquisition, development and maintenance. Each member state implements NIS2 through its own law, so the details depend on where an entity is established and which national authority it reports to.

Asia-Pacific data protection

A legacy system from a business that operated in 14 countries may hold records governed by several national data protection laws at once. Work out which laws apply to which datasets before an incident forces the question.

Control frameworks

If you report against SOC 2 or ISO/IEC 27001, acquired systems are in scope once they are part of the business you describe. ISO/IEC 27001:2022 Annex A control 5.9 covers the inventory of information and associated assets, 5.19 covers information security in supplier relationships, 8.5 covers secure authentication, 8.8 covers the management of technical vulnerabilities, 8.15 covers logging and 8.22 covers network segregation. Under SOC 2, CC6.1 addresses logical access and CC7.1 addresses detecting vulnerabilities and configuration changes. An acquired system with plain-text passwords and shared super-admin accounts would fail several of these at once.

What customers, carriers and drivers should do

If you worked with the former LF Logistics, or with any logistics provider after a claimed breach like this one, here is a practical list. Start with what the company tells you, and use only contacts you already know.

1. Expect shipment-themed phishing. Attackers who hold purchase orders, advance shipping notices and delivery receipts can write very convincing emails about a delayed delivery, a customs fee or a changed delivery address. Verify through your usual account contact, as Maersk advised.
2. Treat bank detail changes as fraud until proven otherwise. Any request to change where you pay an invoice, or where a carrier gets paid, needs a call-back to a known number. This is the most expensive follow-on fraud in logistics.
3. Rotate credentials you shared. If your company holds an API key, SFTP account or portal login for systems of the former LF Logistics, ask your account team whether it should be rotated, and rotate your own side.
4. Drivers: watch for targeted messages. Device identifiers, phone numbers and email addresses are the raw material for convincing texts that ask you to "re-verify" a driver app account. Use only the app and contact numbers your employer or carrier gave you.
5. Change reused passwords. If you ever used the same password on a logistics portal as elsewhere, change it everywhere now, and turn on app-based or hardware-key second factors where offered.
6. Don't go looking for the data. Downloading leaked files to check whether you are in them exposes you to malware and, in some places, legal risk.

Fix it without waiting for upstream

You can't make an attacker's claims true or false, and you can't make an investigation finish faster. What you can do is close the gaps in your own acquired estate this month, without waiting for an integration programme, a vendor or a maintainer. Each of these steps works on its own.

1. Name one owner for every acquired entity's security, with a deputy, and write their names in the asset register today.
2. Pull the outside-in view. List every domain and subdomain from DNS and Certificate Transparency logs for every acquired brand, current and former. Flag every login page, admin console and test instance that answers from the internet.
3. Close or restrict what you can't justify. Put admin consoles behind single sign-on, a VPN or an IP allowlist. Shut down test instances. Record every exception with an expiry date.
4. Count the super admins. In every acquired application, list top-level admin accounts. Remove shared, unowned and leaver accounts, and require MFA on the rest.
5. Rotate privileged and partner credentials. Service accounts, API keys, EDI and SFTP credentials, OAuth grants. Start with systems that hold personal data or partner integrations.
6. Find bad password storage and fix it in code. Search acquired code and database schemas for password fields stored in plain text or with outdated hashes. Migrate to Argon2id, or scrypt where Argon2id is not available, and force resets where the store was plain text.
7. Generate an SBOM for every acquired application and image you can build, and request one from every vendor whose software you inherited.
8. Scan the SBOMs and fix the KEV entries first. Upgrade every component that appears in the CISA KEV catalogue, then work down by reachability and EPSS. Open the fixes as pull requests that the acquired team's own CI tests.
9. Run dynamic tests against exposed apps and the APIs behind mobile apps, starting with authentication and authorisation on driver and partner endpoints.
10. Forward logs. Send authentication, admin and bulk export logs from every acquired system to your central monitoring, with alerts for unusual export volumes and new admin accounts.
11. Cut old data. Apply your retention schedule to driver records, device logs and delivery receipts in legacy systems. Archive what the law requires and delete the rest.
12. Set a retirement date for every legacy system, and keep scanning and patching it until the day it is switched off, then remove its DNS, certificates, firewall rules and credentials.

Most of the risk in an acquired estate sits in open-source components that are known to be vulnerable, and in the time between a fix being published and that fix actually running. When no fix exists at all, the wait can stretch indefinitely. Waiting through either gap 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, Griffin, Safeguard's security model, opens a policy gated pull request that moves the affected dependency to the safe version, and your own CI runs your tests on it before anyone merges. You can run it on one repository or in bulk across every project that carries the vulnerable version. Remediation categories include dependencies, licenses, security posture and findings, and each one is set separately. 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. Auto-merge is a separate switch and stays off by default, so your team decides what merges 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.

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

Safeguard Gold rebuilds patched versions of open-source packages and images from source, signs each build, attaches an SBOM, SLSA provenance and VEX, and serves them from registry.safeguard.sh to your organization. Every Gold artifact is held continuously to zero exploitable critical or high CVEs and a completed license check, with signed build provenance (signed with Safeguard's key and verifiable with cosign, SLSA Build Level 3 as the design target) 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 build of a specific package.

How Safeguard helps with this class of problem

Maersk found and disclosed this incident itself, and the investigation is Maersk's own. Our part is to help teams that buy companies get control of the software and systems they inherit, faster. These are the capabilities that map to the plan above.

Asset discovery with enforcement. Safeguard discovers repositories, images, packages, AI models, SBOMs, vendors and workloads across the estate, and applies guardrails and enforcement to what it finds. For an acquisition, that means the inventory starts from what is actually connected, not from the spreadsheet the seller handed over.

SBOMs and software composition analysis. Safeguard generates and analyses SBOMs in SPDX and CycloneDX, builds a full transitive dependency inventory across major ecosystems and container layers, and enriches every match with NVD, GHSA, OSV, CISA KEV and EPSS data. Reachability analysis ranks the findings that the acquired code actually calls. You can also upload SBOMs, CSAF and VEX documents from vendors, and upload app binaries such as Android APK and iOS IPA files for analysis.

SAST, DAST and posture checks. First-party SAST reviews acquired code for weaknesses such as injection flaws and insecure password handling. DAST runs scoped dynamic tests against targets you have verified you own, and API security testing covers authenticated APIs, including authorisation flaws such as broken object level authorisation. Cloud posture checks cover AWS, Azure and GCP accounts, with Kubernetes posture, infrastructure-as-code and database posture checks alongside, and on-premises VAPT through the CLI covers networks, devices and Active Directory at sites such as warehouses.

The local runner CLI for teams not yet integrated. Acquired teams often can't grant repository access to a new parent on day one. With the local runner CLI, the scan runs on their machine and uploads the SBOM and results, so you can see risk in their code before the integration programme catches up.

Third-Party Risk Manager. Inherited vendors go into a vendor directory with contracts, SLAs and risk tiers. You can request SBOMs and evidence from them, score them across vulnerability, compliance, component and operational risk, and monitor them continuously, with alerts for new critical vulnerabilities and KEV additions routed to an owner.

Policies and gates. Organisation-wide policies, which you can write from plain-English prompts, are enforced as gates at build, CI and release, with actions to block, warn, notify or require approval. A rule such as "no release from any acquired entity ships with a KEV-listed component" applies to the new team the day its pipelines connect.

Package Firewall. Package Firewall runs as a local install-time proxy for npm and pip on developer machines and CI runners, and blocks malicious, typosquatted and dependency-confusion packages before they install. That helps when a newly acquired team is still working from its own package habits.

Runtime guardrails. Guard provides runtime protection inside your applications with guardrails you define, which helps keep legacy services under watch while their retirement date approaches.

Compliance evidence. The compliance suite brings frameworks, controls, evidence, monitoring, questionnaires, risks and vendors into one place, so acquired systems land as evidence against the SOC 2, ISO/IEC 27001 and GDPR controls they affect. Safeguard itself is SOC 2 Type I and Type II audited.

You can see the platform at https://safeguard.sh.

FAQ

What happened at Maersk?

On 11 November 2026, Maersk said it had identified unauthorised access and data extraction from "one of our local legacy systems from a previous acquisition." It said its findings so far strongly suggest no sensitive data was disclosed, that the incident is isolated to a local system, and that it does not anticipate disruption to customer operations.

Was LF Logistics breached?

Maersk has not said which acquisition the system came from. The extortion group WhiteArmor claims the data came from the "OCF/LF Logistics" platform, and several outlets have connected it to LF Logistics, which Maersk acquired in 2022. Maersk has not confirmed that link.

How much data was stolen?

Maersk has not said. WhiteArmor claims about 100 GB, including driver records, mobile device logs and delivery receipts. Those claims are unverified.

Who is WhiteArmor?

According to ISMG, a data extortion and ransomware group active since 21 October 2026 that has claimed attacks on more than 20 organisations. Little else about it has been reported.

Were Maersk's shipping operations affected?

Maersk said it does not anticipate disruption to operations for customers and that customers can continue to book and manage shipments as usual. It also said it found no indication of impact on other Maersk systems or on customer and partner systems connected through APIs and EDI.

Why are acquired systems a common breach target?

They often run outside the acquirer's identity, logging and patching controls, keep old design choices such as shared admin accounts, hold years of data, and stay online for years while integration is planned. Attackers look for the least protected part of a large group, and that is often what it bought most recently.

How do SBOMs help with M&A security?

An SBOM lists every component in an application. Generating SBOMs for acquired software shows which known-vulnerable components the deal brought in, lets you prioritise those on the CISA KEV catalogue, and answers "are we affected?" quickly when the next widely exploited flaw appears.

What did the Marriott and Starwood case establish?

The UK ICO fined Marriott £18.4 million in 2020 over a breach of Starwood systems that began in 2014, before Marriott acquired Starwood in 2016, and was not detected until 2018. The ICO said due diligence on data operations "is not time-limited or a 'one-off' requirement."

How does Safeguard help acquirers with inherited systems?

Maersk identified and disclosed this incident itself. Safeguard helps acquirers inventory, SBOM, scan and remediate the software and systems they inherit, with policies and gates that apply to an acquired team from the day its pipelines connect.

Sources

All accessed 14 November 2026.

• A.P. Moller-Maersk, "IT security incident", 11 November 2026: maersk.com
• A.P. Moller-Maersk, agreement to acquire LF Logistics, December 2021: maersk.com
• A.P. Moller-Maersk, "Maersk completes acquisition of LF Logistics", 31 August 2022: maersk.com
• A.P. Moller-Maersk, "Update on LF Logistics and Fung Omni further integrating with Maersk", 3 April 2023: maersk.com
• The Register, "Shipping giant Maersk probes 'IT security incident,' data theft", 11 November 2026: theregister.com
• BleepingComputer, Maersk data breach and WhiteArmor claims, 11 November 2026: bleepingcomputer.com
• Security Affairs, WhiteArmor claims against Maersk, 11 November 2026: securityaffairs.com
• ISMG GovInfoSecurity, "Maersk Probes Ransomware Claim Tied to Legacy System", 11 November 2026: govinfosecurity.com
• Ingeniøren, Danish report on the WhiteArmor claim, 10 November 2026: ing.dk
• Cybernews, "Maersk confirms cyberattack after hackers access old IT system", November 2026: cybernews.com
• UK Information Commissioner's Office, Marriott International Inc penalty notice, 30 October 2020: ico.org.uk
• Regulation (EU) 2016/679 (GDPR): eur-lex.europa.eu
• Directive (EU) 2022/2555 (NIS2): eur-lex.europa.eu
• NTIA, "The Minimum Elements For a Software Bill of Materials (SBOM)", July 2021: ntia.gov
• OWASP, Password Storage Cheat Sheet: cheatsheetseries.owasp.org
• CISA, Known Exploited Vulnerabilities Catalog: cisa.gov