Signing Keys by Proxy

Every signature answers two questions: who issued the key, and who granted the signer the right to use it. When a consultancy, a plugin or a platform signs on your behalf with a certificate authority (CA) you never chose, you inherit that CA by proxy: its trust, its revocation service, its jurisdiction, and its failures. October 2026 showed what that costs when the CA is distrusted. This article sets out when you use a CA by proxy, what locks out when its chain breaks, how ECC/SAP signing fits, what each market requires, and how to build a Globalization MVP security first, with a cutover checklist to get there.

What are signing keys, and where are they used?

A signing key is a business's digital seal. It comes in two halves. The private key stays with whoever signs, like the stamp locked in a notary's drawer. The public key is shared with everyone, so anyone can check that a stamp is genuine without asking the signer. A valid signature proves two things: who signed, and that nothing changed after they signed. Change one character of a signed contract, firmware file or code release and the check fails.

You already rely on signing keys every day, usually without seeing them:

The business question is never only "is it signed?" It is also: whose key, issued by whom, and who granted them the right to sign for us? A developer's key proves who pushed, but not whether they were allowed to push to that repository. A consultant's certificate proves who signed, but not whether they could sign for your company. That gap between issuer and grant is what this article is about, and it grows when the key belongs to someone else: a vendor, a plugin, or a consultancy signing by proxy.

Why this matters now: keys have to move on events

Historically, signatures lived inside SLA-bound enterprise applications with a heavy price tag, such as SAP and AEM, and governance of those keys was assigned to a consulting team. The keys sat inside the application, and changing who could sign meant a change request, a consulting ticket and a release window. That worked when signing happened a few times a quarter.

It also fitted what those systems were built for. SAP grew from accounting: accumulated ledger rows, in effect spreadsheets at enterprise scale, posted in batches by trusted staff on an internal network. Records like that never needed memory safety, because nothing untrusted reached the code at run time. Attestation was a timestamp, the posting date and the change log, not a signature anyone outside could verify. Data subject request (DSR) evidence was held in pay-to-use data repositories: vendor add-ons and archives billed by volume or by query, so proving a deletion meant paying to read your own records.

AI work signs on every event: each pull request, each consent change, each new market. Three capabilities stay blocked until the organization can exchange keys on the event, issuing, rotating or revoking a key or grant at the moment something happens:

The risks of leaving keys there. When signing and its governance sit with an external team inside an SLA application, the organization carries risks it doesn't control:

Distributed keys and rolling data gating. The answer to these risks is to spread keys across the systems that act, each with its own scoped grant, and to have AI check every write against consent, market rules and mandates as it arrives: a gate that rolls with the data instead of a batch review after it. That model only holds if nothing writes around the gate. A plugin that hard-codes upserts into the data store, or runs in a runtime without memory safety, is a side door: its writes carry no signature, and a single memory-corruption bug can hand an attacker the keys and the write path together. October 2026 made the point twice: php2shell gave unauthenticated code execution in the PHP runtime under every WordPress, Drupal, Magento, Joomla and Laravel host, whatever the plugin code, and an AI gateway package was compromised for the second time this year, again stealing signing keys and AI provider keys from the environment it ran in.

Key exchange on events is what moves signing out of the SLA application and into infrastructure the organization owns. The rest of this article shows what that takes: whose keys, which grants, and where each market's rules apply.

1. When you use a CA by proxy

Three parties are involved: the client (you), the consultancy or vendor, and the CA that issued the consultancy's certificate. Whether you use that CA depends on whose certificate signs and who runs the system.

Even as a relying party only, you depend on the CA for revocation checks (its OCSP responder or CRL; long-term validation helps only if it was embedded at signing), trust in its root, and the legal weight of the signature in your jurisdiction.

These are patterns, not claims about any firm. A contract, or the certificate chain of a signed PDF, shows which provider a given consultancy uses.

2. Why it is not hypothetical: October 2026

A key ceremony at eMudhra on 30 April 2025 generated eight intermediate CA keys with too little randomness. Between 17 and 20 October 2026 a researcher recovered all eight private keys from the public certificates, and Chrome, Mozilla, Apple and Microsoft blocked them: six TLS intermediates and two code-signing intermediates. Chrome removes the emSign ECC Root CA - G3 from devices from 27 October. Go, NSS, Ubuntu, Debian and Composer shipped trust-store fixes on 20 October, and the Node.js releases of 21 October also reject the chains. India's Digital Signature Certificates run under India's own CA licensing rather than the browser root programs and, as reported, were not directly affected.

The keys were not stolen; they were computable. An audited process with certified hardware still produced weak keys, so the lesson is about provenance: know which of your certificates chain through which CA, and sign your own records with keys you own and can retire. Background: Hydrogen or bespoke stack, Org Trust Layer, and reporting by The Hacker News and Help Net Security.

The same month, on the shop floor: refrigeration controllers in France and the UK

The eMudhra keys were weak; in October's other incident there were no keys at all. On the night of 11 October 2026, attackers reached the refrigeration controllers of hundreds of French supermarkets, including Intermarché, Netto, Coopérative U, Carrefour, Monoprix and E.Leclerc stores. The Danfoss controllers ran web servers open to the internet, and many accepted the username admin with the current date as the password. The attackers set cases to defrost with food inside: some reached about 50 °C within six hours, some equipment melted or caught fire, and the change went unnoticed because it raised no alarm and no staff were present. No data was stolen; the losses ran to tens of millions of euros. Danfoss had shipped a fix for its current AK-SM800A series in August 2025, but older units were end-of-life. The Prime Minister asked ANSSI to investigate, and its director said the controllers urgently needed disconnecting from the internet.

On 13 October, UK Cyber Defence found more than 800 UK refrigeration and building controllers with their login pages on the open internet. By early November, UK victims were confirmed: a West London wholesaler, Langridge Organic, found six of its ten cold-room controllers, running Copeland's Dixell XWEB software, set to defrost with a 150 °F maximum and their temperature alerts switched off. Manual checks saved its stock. The NCSC said it was aware of a small number of affected UK organisations. On 2 November, similar attacks hit supermarket refrigeration in Belgium, Luxembourg, the Netherlands, Sweden, Estonia, Ireland and Portugal. No one has been publicly identified as responsible.

Both incidents are the same signing-keys problem. A controller that accepts any command from anyone who reaches its login page has no issuer (no device or operator certificate) and no grant (nothing says who may change a setpoint, by how much, or when). The attacker also switched off the alarm through the same channel, so the record of what changed was lost with it. Sources: Wikipedia, Public Sénat, and The Grocer on UK exposure and UK victims.

Households: where humans matter the most

Security counts the most where humans matter the most: in our households. The October attacks hit shops, but the same class of device sits in homes: fridges and freezers, heat pumps, boilers, thermostats and EV chargers, all on the household network and most talking to a manufacturer's cloud. A home has no security team and no morning temperature check. If a supermarket controller can be set to defrost from the internet, a home appliance with an open login page or a default password can be too, and its data stream says far more about the household: when the fridge door opens, when the heating comes on, when nobody is home.

Why households wire them up. The benefits are real, and they are why the answer is to secure the stream, not to unplug:

The TV and the phone have become the home's micro-network. Many households now run the home from a phone on the sofa and a smart TV on the wall: casting to the screen, using the phone as the remote, and letting the TV act as the hub for lights, cameras, speakers and appliances. Newer devices join a local mesh (Thread) and a common smart-home standard (Matter), so the phone, the TV and each device talk inside the home, without a round trip to every maker's cloud. That is good for speed, for working when the internet is down, and for privacy.

It also makes the TV and the phone the gate. Whatever reaches them can reach every device paired to them, and TVs often run for years without updates while streaming viewing data to their makers. Matter shows the right pattern: every certified device carries its own device attestation certificate from its manufacturer, and pairing gives it a fresh operational certificate issued by the household's own network, so the household, not the maker, holds the keys that let a device join or leave. The household's gate should work the same way for everything else: local first, encrypted, and under keys the household holds.

Cameras show what is at stake. In late November 2025, Korean police arrested four people over the hacking of about 120,000 internet-connected cameras in homes and businesses, including private homes, a Pilates studio and a gynecology clinic. Two of them accounted for most of the hacks and made sexually exploitative videos from the footage, which were sold on an overseas site; police also arrested buyers and moved to close the site. The way in was simple: the cameras had weak passwords, such as repeated characters or sequential numbers and letters. Many had been installed to watch over children and pets. A leaked video can't be recalled the way a spoiled freezer can be restocked, which is why the stream itself has to be gated. Sources: BleepingComputer, Kaspersky, The Star.

Households need two things before anything else: an encrypted data streaming gate, and hardened firmware.

The rules are arriving. The UK's product security regime has banned universal default passwords on connectable consumer products since April 2024 and requires a stated support period. In the EU, the Radio Equipment Directive's cybersecurity requirements have applied to wireless devices since August 2025, and the Cyber Resilience Act adds vulnerability reporting from September 2026 and full security obligations, including secure updates and an SBOM, from December 2027.

The same controls protect lights-out sites, where cold rooms, chillers and server cooling run with nobody on the floor; see Entitlement Security.

3. AI security: trust and boundary lockout

A distrusted chain is not a warning. Browsers and runtimes refuse the connection, and everything that depended on it stops.

Recover faster: keep an inventory of which certificates chain through which CA, automate reissue (ACME) with a second CA ready, queue DSR events so they can be replayed with their timestamps, and sign records with keys you own so they still verify when a public CA does not.

4. Tools and permissions: a certificate is not a grant

A CA proves who holds a certificate. It does not prove what they may sign or do. That needs a grant from the organization: who, what, for how long, revoked on exit. For AI agents the grant is a mandate: scoped to tools and markets, expiring, and checked on every action.

Certificates you control

Assets that prove provenance (PDFs and firmware, images, 3D files, docs) are vaulted the same way: each file under its own key, every upload certified, every download granted and recorded in a hash-chained ledger. See the Protected Firmware Asset Management and Download Service and Firmware asset publishing.

ECC/SAP signing: the same scrutiny, plus two ECC-specific risks

• STRUST doesn't update itself. Browsers and runtimes shipped the distrust in October; an ABAP trust store changes only when someone edits it. Check every PSE in STRUST, plus ADS and Java stack keystores.
• The S/4HANA move carries trust. A system conversion (SUM with DMO) migrates the PSEs too. Clean out stale or proxy certificates first; ECC mainstream maintenance ends in 2027.
• Unsigned spreadsheets are the weakest link. Hash each handoff file and record it, signed with a key you own.

Stores: POS registers in sync with warehouse and RMA systems

A point-of-sale register is a device that moves money and stock. When registers, the warehouse management system (WMS) and the returns system (RMA, return merchandise authorization) sync by batch file or shared credentials, nobody can say which register recorded a return, who authorised the refund, or whether the item ever reached the warehouse. Keeping them in sync safely means every step is a signed event from a known device, under a grant, and each system acts only on events it can verify:

The same rules from the rest of this article apply: a certificate per register and scanner, revocable one at a time; no plugin writing stock or refunds around the gate; and a ledger that shows, for any refund, which register, which person or agent, and which warehouse receipt it rested on.

5. Knowledge base: publish, don't unlock

Chatbots that answer from locked PDFs, docs, Markdown and spreadsheets, or from raw images and 3D files (JPG, PNG, SVG, WebP, OBJ, STL, FBX, GLB), read sources nobody approved, signed or versioned. A knowledge base for AI is published once as structured records carrying issuer, version, market, locale and consent scope, hashed and signed with a key you own. Media and 3D files become a manifest (alt text, dimensions, product link, licence) while the file stays in the vault under its own key.

The chatbot then climbs a decision ladder on that evidence: retrieval (RAG), corrective retrieval when evidence is weak (CRAG), a locale or personalisation adapter (LoRA) only where consent allows, and a hand-off to a person when the answer carries money, law or risk. No rung opens a locked file, no agent acts without a mandate, and price and stock come live from the system of record, never from embeddings. More in The AI ladder.

Chatbot plugins: what they can't include

Most Shopify stores answer shoppers through a third-party app: helpdesk suites such as Gorgias, Zendesk and Sprinklr; SMS and conversational marketing such as Attentive and Postscript; on-site chat such as Tidio, Shopify Inbox and Intercom; and the AI agents each of them now adds. They run the bot as a third-party script or service with the vendor's own storage, keys and certificates. That makes them a signing-keys-by-proxy problem of their own: whatever the shopper types lands in the vendor's transcripts, in the vendor's region, under the vendor's CA. Three things should stay out of them.

Check each vendor's terms and data-processing addendum for where transcripts are stored and how card numbers are masked; the point is that none of those choices are yours.

What each kind of app holds, and so what moves by proxy when you install it:

Chatbot build requirements

A headless Shopify proof of concept, the chatbot preview built on public product feeds and chatbot articles, shows the gap this section describes. It uses public data on purpose, to show the difference between being visible and being governed. Anything public can be viewed by AI, but that does not incorporate it into a knowledge base corpus with rules and permissions: no issuer, version, locale or consent scope, and no grant saying who may use it for what. Public articles an AI can read are still ungoverned until they are published as records. Its chatbot still answers from legacy Sprinklr articles that were never published through the knowledge base ladder, so its answers carry no issuer, version, locale or consent scope, and nothing traces back to a canonical record. Closing that gap is the build:

Why an ungoverned ladder hallucinates. A chatbot or AI escalation ladder that retrieves from public docs without a governed corpus pulls anything that matches: an old article, another market's price, a machine translation, a page written for a different audience. With no guardrails, no global ISO rules and no personalised consent state, it has nothing to check an answer against, so it fills the gaps:

The publishing side starts with a curated knowledge base feed: support articles tagged by product family, searchable and filterable, one answer per question, with step-by-step instructions and diagrams. Curation is the first rung. The next is publishing each entry as a signed record with its issuer, version, locale and consent scope, and pointing the chatbot at those records instead of the legacy helpdesk.

• Migrate each legacy helpdesk article (Sprinklr here; Gorgias, Zendesk or another helpdesk elsewhere) into a canonical record (one answer per question), then stop reading it live
• Publish every record with issuer, version, market, locale and consent scope, hashed and signed with a key you own
• Re-index retrieval from the published records only, filtered by locale
• Hand off checkout by URL to Shopify; take no card data and no personal data in chat
• Trace every answer to its record, its issuer and its grant
• Retire the helpdesk as a knowledge source once the published set covers its questions

LoRA audience training, linked to BigQuery and organic lookup

Two things are easy to confuse. Audiences decide who gets a personalised answer; LoRA adapters decide how the model writes for them: tone, vocabulary, format. BigQuery holds the audience, organic lookup supplies the evidence of how each market actually asks, and the adapter is trained only on de-identified pairs with a training basis. Personal data never goes into model weights, because an erasure request can't reach inside a trained model.

BigQuery (consent-filtered, keyed by ISO country, language, currency, UTC time)
  ├─ audiences ─────→ GA4 export + Shopify orders → segments, pLTV (BigQuery ML)
  │                     → cohort labels, held below a minimum cohort size
  ├─ organic lookup ─→ Search Console bulk export: queries by country, language, device (aggregated)
  │                     → KB gaps: questions searched but not answered → publish records
  │                     → evaluation set: real phrasing per market
  └─ training pairs ─→ redacted, de-identified question-and-answer pairs + cohort label
                        with training consent → clean room → LoRA adapter per market × cohort
                        → registry: dataset_hash, record_count, consent basis, retire_by
Chatbot: pickAdapter(locale, cohort, consent) → base model + adapter; facts from published records (RAG)

Rules that keep it governed:

• Training consent is its own scope. Marketing or personalisation consent is not consent to train; only records with a training basis enter the clean room.
• Minimum cohort. A cohort below the threshold gets no adapter and no label; it falls back to the locale adapter.
• In-country training. Korean data trains only on Korean-hosted systems; each market's rule from section 6 applies to training as well as storage.
• Retire and retrain. Every adapter carries retire_by; a withdrawal is honoured by retraining without the withdrawn records, not by editing weights.
• Organic lookup feeds the corpus first. A question people search for that the knowledge base can't answer becomes a published record before it becomes training data, so the adapter changes how the answer is written, never what it says.

Background: Google audiences and conversions with Vertex AI, and where LoRA fits and the clean room.

6. Globalization: rules management by market

Each market sets whether data must stay in country, on what basis it may leave, and which Cloudflare and Xano options keep it where it belongs.

Rules are summarised, not legal advice. Check Cloudflare's and Xano's current region lists for your plan; the AI cross-border requirements checklist goes deeper on transfer bases.

7. Globalization MVP, security first

Build the trust layer before the first market, so every market after it is a variable and a region, not a new integration.

Phases 0 and 1 ship before any market. Every later phase inherits the keys, grants, consent gate and ledger, which is what keeps it an MVP rather than a rebuild per market.

Publishing requirements for the MVP

Four things are published in every market, and each is a signed record, not a file someone copies into a system:

A new market reuses all four: its firmware channel, its Markdown slice, its grants and its ladder are configuration on the same rails, not a new integration.

8. AI cutover checklist

Move AI onto keys you own and grants you can revoke, without a lockout: inventory first, switch in a window, then retire what no one granted.

Before cutover: inventory

• Inventory every certificate, with its issuer chain: TLS, STRUST, ADS, Java keystores, CI runners
• List every signing key and who holds it: staff, consultants, DSC tokens
• Publish your own key set (JWKS) for the records you sign, so they verify offline
• Write the grants: who may sign or act on what, for how long
• Publish the knowledge base as signed records with content hashes; no locked files
• Map each market's rule: residency, transfer basis, Cloudflare and Xano region
• Make DSR events replayable: queue consent, opt-out and deletion with timestamps
• Name a second key holder: no key or rotation depends on one developer; two approvers and a written runbook
• List every external team and plugin with access: its seat licence, its credentials and what it can write
• Secure the exit before the contract ends: export the knowledge base, prompts, labelled data and adapters, and confirm the export opens
• Find writes around the gate: plugins with hard-coded upserts, or running without memory safety

Cutover window: switch

• Agents act only under mandates: scoped, expiring grants per tool and per market
• mTLS per service and agent: a client certificate each, revocable one at a time
• Retrieval reads published records only, locale-filtered; never private buckets
• Price and stock stay live from the system of record, never embeddings
• Keep the old path read-only: switch traffic, don't delete; roll back by route
• Watch the lockout signals: handshake failures, denied tool calls, stalled feeds
• Move plugin writes behind the gate: every write a signed event; no plugin holds signing keys or direct database access
• Replace standing vendor credentials: a scoped, expiring grant and certificate per vendor, revocable alone
• Cover every time zone: your own on-call staff hold pre-approved emergency mandates

After cutover: retire

• Revoke what no one granted: consultant and proxy certificates, old API keys
• Retire old keys and republish the key set; old records still verify
• Replay the DSR queue and log a receipt from every system that acted
• Prove residency: each market's data in its region, with evidence
• Embed LTV in signed documents, so revocation info and timestamps travel with them
• Schedule trust-store reviews: browsers patch themselves; STRUST and runtimes don't
• Rehearse a breach: revoke a key, replay the queue and produce the timeline within GDPR's 72 hours
• Close external access at contract end: only after the export is verified

Contract clauses to ask for

• Disclose every provider: every trust service provider and CA used for your signers or systems.
• Certificates issued to the client: certificates installed in your systems name you, not the consultancy.
• Embed LTV: revocation info and timestamps embedded, so documents stay verifiable after the relationship ends.

The cutover is done when every key has an issuer you chose, every action has a grant you can revoke, and every market's data has a region you can prove.

Related

• Org Trust Layer: your own CA, fewer plugins
• The AI ladder: retrieval, adapters, humans, and who holds the keys
• Entitlement security
• Hydrogen or bespoke stack
• AI cross-border requirements checklist
• Chatbot preview and curated knowledge base feed

Patterns, not claims about any firm. eMudhra incident details per The Hacker News and Help Net Security, October 2026. Country rules summarised; not legal advice.