Architecture

Policy bundles and device compromise

Your rules reach each browser as one signed file, a policy bundle. This page explains what’s in it, how a browser decides to trust it, and what someone who controls a laptop, or breaks into LayerT, can and can’t do with it.

Describes LayerT as built on 3 October 2026. Anything not built is labelled.

In plain words

When your IT team publishes rules in the admin console, LayerT packs your organisation’s whole rulebook into one file, called a policy bundle, and signs it. Every LayerT extension has the matching public key built in, so a browser can tell a genuine bundle from a forged or altered one. It refuses anything that doesn’t check out.

Why it’s signed. The bundle travels over the internet and sits on laptops nobody watches every minute. The signature means nobody between LayerT and the browser can change a rule, add an exception or switch enforcement off. Nobody can hand a browser another organisation’s rules, or an older version of yours, either.

Why it expires. Every bundle is good for 7 days, and LayerT re-signs it automatically well before then. Expiry stops a laptop living forever on old rules: a bundle that nobody can refresh eventually stops counting as current.

What happens offline. A browser that can’t reach LayerT keeps using its last genuine bundle. New rules, new approvals, revoked devices and the emergency stop can’t reach it until it reconnects. If it stays offline until its bundle expires, it doesn’t quietly fall back to allowing everything. On the sites your blocking rules cover, it stops the actions those rules cover and asks the person to reconnect.

What’s never in it. Passwords and one-time codes for shared accounts never travel in a bundle. They’re sent separately, for one sign-in at a time. A bundle does hold work email addresses and the exceptions your approvers granted, so treat it as company data.

Where the signature stops. The signature protects a bundle on its way to the browser. It doesn’t protect it after it’s saved. Someone who can write to the browser profile’s extension storage, or who has administrator rights on the laptop, can defeat enforcement on that laptop. Device management closes that gap, as the section on device takeover and breach explains.

What’s inside a bundle

A bundle is one JSON document for your whole organisation. Here’s a shortened example with fictional values:

{
  "bundleVersion": 57,
  "issuedAt": "2026-09-18T09:00:00.000Z",
  "expiresAt": "2026-09-25T09:00:00.000Z",
  "tenantId": "3f1c2a9e-7b44-4d2e-9a51-0c6e1d2b8f10",
  "tenantDisplayName": "Acme Corp",
  "killSwitch": false,
  "critical_update": false,
  "revoked_devices": ["b7e0c1d2-5a6f-4e3b-8c9d-1a2b3c4d5e6f"],
  "classifiers": [
    { "id": "corp_email", "type": "email_domain", "value": "acme-corp.example" }
  ],
  "rules": [
    {
      "id": "rule_postbox_work_only",
      "name": "Sign in to Postbox with a work account only",
      "enabled": true,
      "event": "form_submit",
      "urlMatch": { "type": "glob", "patterns": ["https://*.postbox.example/*"] },
      "selectors": [{ "css": "input[name=login]" }],
      "valueMatch": { "op": "not", "operand": { "type": "matches_user_attribute", "field": "allowed_postbox_accounts" } },
      "action": {
        "type": "block_with_request_bypass",
        "message": "Use your Acme Corp account here.",
        "bypass": { "mode": "request_bypass", "justificationRequired": true }
      },
      "audit": { "include": ["url", "value"], "redact": "partial" }
    }
  ],
  "exceptions": [
    {
      "id": "0b9c8d7e-1111-4222-8333-944455566677",
      "ruleId": "rule_postbox_work_only",
      "subject": { "userId": "jc_alice_chen" },
      "matchedValue": "[email protected]",
      "expiresAt": "2026-10-01T00:00:00.000Z",
      "grantedBy": "[email protected]",
      "grantedAt": "2026-09-17T08:12:00.000Z",
      "justification": "Monthly upload to the Vendor Reports portal"
    }
  ],
  "groups": {},
  "user_attributes": {
    "[email protected]": { "allowed_postbox_accounts": ["[email protected]"] },
    "[email protected]": { "allowed_postbox_accounts": ["[email protected]"] }
  },
  "signature": "ed25519:q8Vd…(64 bytes, base64)…",
  "signatureKeyId": "prod-v1"
}

Field by field:

Field	What it holds
`tenantId`, `tenantDisplayName`	Your organisation’s id, which ties the bundle to your organisation, and the name LayerT shows in its prompts
`bundleVersion`	A number that goes up by one with every new bundle. A browser accepts only a higher number than the one it holds
`issuedAt`, `expiresAt`	When the bundle was signed, and when it stops being current: 7 days later
`rules`	Every rule: when it acts (its trigger), where it applies (site patterns), which fields it watches (CSS selectors), which values trigger it, what happens, the message people see, and what the audit log records
`classifiers`	Named value tests that rules can share, such as “an address at our email domain”
`exceptions`	Every live approved exception: the rule, the person’s directory id, the exact value that was approved, when it expires, who approved it and when, and the reason the person gave
`groups`	Empty. Group memberships don’t travel in a bundle: each browser asks about its own person’s groups separately (see “The person’s groups, separately” below)
`user_attributes`	Each active person’s own lists, such as the accounts they’re allowed to sign in with
`killSwitch`	The emergency stop. When it’s on, the browser enforces no rules
`revoked_devices`	The ids of browsers an admin has revoked
`critical_update`	Marks an urgent version: an emergency stop, a rollback or a revocation. Today the extension doesn’t fetch these any sooner (see “Emergency stop and rollback” below)
`gateways`	Only if you use gateways Early access: each gateway’s name, region, host name and port. No IP addresses
`signature`, `signatureKeyId`	The Ed25519 signature over everything above, and which key made it

What’s never inside

Shared-account passwords, authenticator setup keys or one-time codes. When someone signs in to a shared account, the browser fetches a separate, single-use grant for that one sign-in and keeps it in memory only. It’s never part of a bundle and never saved to disk.
Sign-in recipes. The steps LayerT follows to fill a vendor’s sign-in form travel with that grant, and are signature-checked separately.
Device tokens or keys. The bundle names the key that signed it. It never contains a key, and the key each browser makes for itself never leaves that browser.
Who is in which directory group. A browser learns its own person’s groups, separately, and nobody else’s.
What people type as they browse. Rules carry patterns, and what a rule matched goes to the audit log, separately. The only typed values a bundle carries are the approved values in live exceptions.
Gateway IP addresses.

Inside, and personal

Every browser gets the whole organisation’s bundle. Today every browser in your organisation receives the same bundle. So every laptop with an approved browser holds the whole organisation’s lists (other people’s allowlists) and every live exception, including the value that was approved, who approved it and the reason given. It no longer holds group memberships. The rules are in it too, so anyone who reads a bundle can see exactly what’s watched. LayerT’s design calls for bundles scoped to one person, but that isn’t built. Until it is, treat a bundle as internal company data, and ask approvers and requesters to keep reasons free of anything that shouldn’t be on every laptop.

The person’s groups, separately

A rule can apply to a directory group. A browser doesn’t need the whole organisation’s membership for that, only its own person’s, so group memberships are kept out of the bundle.

At every policy sync, each browser also asks LayerT which groups its own person is in. LayerT reads your directory as it stands and answers with that person’s groups and nothing else. A browser never learns who else is in a group.
The answer is signed with the key that signs policy, in its own format, and is valid for 24 hours. The browser keeps it only if the signature verifies and the answer is for this browser and this organisation.
A change in your directory reaches a running, connected browser within about 15 minutes. An offline browser keeps its last answer for up to 24 hours, and an open page keeps what it loaded with until it’s reloaded or its address changes.
A browser with no current answer fails closed on pages where a blocking rule names a group (see “Expire and fail closed” below).

The life of a bundle

A bundle is checked once, when it arrives. After that the browser trusts what it saved, which is why the laptop itself has to be managed.

Publish

Every change that affects what browsers enforce produces a new bundle:

an Owner or IT Admin publishes pending drafts (optionally after a second author reviews them),
an approver grants access, which adds an exception,
someone revokes an exception, or switches a rule on or off,
an Owner or IT Admin revokes a browser, or restores one,
the Owner pulls or releases the emergency stop,
an Owner or IT Admin rolls back,
your directory changes (people join, leave or change groups), picked up by an hourly job.

Each new bundle takes the next version number for your organisation under a lock, so two changes at once can’t produce the same version. The signed document is stored with a fingerprint of its contents and a link to the version before it.

Compile and sign

LayerT assembles the bundle, then writes it out in a canonical form: keys sorted, signature fields left out, so the same content always produces the same bytes. Those bytes are signed with Ed25519.

The private signing key is held in a key service, and it can’t be exported. LayerT’s servers send the service the bytes and get a signature back. The key is software-protected: the service offers this type of key (Ed25519) in software only, so it is not held in a hardware security module. Production configuration refuses to start with a local key file. This is built and in use in LayerT’s test environment. Production, which will hold the key in Google Cloud KMS, is not deployed. Development builds sign with a local key, and a production build of the extension refuses to trust it.

The same key signs bundles for every organisation. It also signs two other things: the identity a browser is bound to when it enrols, and sign-in recipes. It signs the answer each browser gets about its own person’s groups too. Each kind is written in its own format, so one can’t be passed off as another.

Several public keys can be built into the extension at once. To replace the signing key, LayerT ships an extension that trusts both the old and new keys, waits for it to roll out, switches signing to the new key, and removes the old one in a later release.

Deliver

The browser asks for the latest bundle:

every 15 minutes,
when the browser starts and when the extension is installed or updated,
when the person moves to a new page (at most every few seconds),
when someone presses Sync now on LayerT’s options page,
and every 30 seconds while a page is showing the “Connectivity required” card.

It asks over HTTPS with its own device token, which says which organisation it belongs to. A browser that is still waiting for an administrator’s approval, or was declined, is refused and gets no bundle. The request is conditional: if nothing has changed, LayerT answers “not modified” and nothing is downloaded. LayerT only ever serves your organisation’s latest bundle.

Verify in the browser

Before the browser uses a new bundle, it runs these checks, in this order, with the browser’s own Web Crypto implementation:

Version. It must be higher than the version already stored. This stops an old bundle being replayed.
Organisation. It must belong to the organisation this browser is bound to. The browser binds to its organisation when it accepts its first genuine bundle.
Key. It must name a signing key built into the extension.
Format. The signature must be a well-formed Ed25519 signature.
Signature. The signature must verify over the canonical bytes.
Expiry. It must not have expired, judged by the laptop’s clock.

If any check fails, the new bundle is thrown away and the browser keeps the one it had. Only a bundle that passes every check is saved.

Store on the device

The bundle is saved in Chrome’s extension storage inside the person’s browser profile, as plain JSON. LayerT doesn’t encrypt it: at rest, it’s protected by the laptop’s disk encryption. The same storage holds the browser’s enrolment (its short-lived device token; there is no long-lived refresh credential) and any audit events not yet sent, which can include values people typed. It also holds the signed answer about that person’s groups. The browser’s own signing key is kept separately by the browser, in a form that can’t be exported.

Checked on arrival, not on every read. The browser verifies a bundle once, when it arrives. After that it enforces whatever is in storage, without checking the signature again. This is why the integrity of the browser profile, and so of the laptop, matters as much as the signature does.

Enforce

On each page, LayerT’s content script asks the extension for the rules that match the page’s address, then acts on form submissions and pastes into the fields those rules name, before the site’s own code sees them. Rules for typed text and for files given to the page act there too. An exception applies only to a “block with a request” rule, and only when the rule, the person and the value all match exactly and the exception hasn’t expired. How rules behave in the page is on Signed policy and enforcement.

Expire and fail closed

A bundle lasts 7 days. An hourly job re-signs your organisation’s bundle, as a new, higher version with the same content, once 48 hours or less remain. LayerT’s monitoring flags any organisation whose newest bundle comes within 24 hours of expiring.

If a browser’s bundle does expire, because it couldn’t reach LayerT for days:

on pages covered by a block or force sign-out rule, every form submission, and every paste into the rule’s fields, is stopped with a “Connectivity required” card that offers no way round it,
a file given to a file rule’s fields, and Enter in a field a typing rule watches, are stopped the same way, without reading anything,
warn and monitor rules keep working,
the last bundle’s emergency stop and revoked-device list still apply,
the card clears by itself within about 30 seconds of a fresh bundle arriving.

A browser that doesn’t know its person’s groups behaves the same way, even with a current bundle. On a page where a blocking rule names a group, the action is stopped until a signed answer arrives.

Emergency stop and rollback

The emergency stop is for when a rule is wrong and needs to be off everywhere now. Only the Owner can use it. It publishes a new bundle with enforcement switched off: every page then passes through, and audit logging carries on. Owners and IT Admins are told it happened. It switches enforcement off. There’s no switch that locks everything instead. A bundle that pulls or releases the stop lasts 24 hours rather than 7 days, and the hourly job keeps it re-signed.

A rollback publishes an earlier version’s rules, value tests and emergency-stop setting as a new, higher version. It keeps today’s exceptions (dropping any the restored rules no longer allow), lists and revoked devices. Rolling back to a version from before an emergency stop lifts the stop, and the audit log records that. Because browsers only accept higher versions, no browser ever goes backwards.

Urgent isn’t faster, yet. Emergency stops, rollbacks and revocations are marked urgent in the bundle, but today the extension doesn’t act on that mark. They reach a browser like any other new version: seconds after the person next moves to a new page, or within 15 minutes if the browser is idle.

Device takeover and breach

The signature and the expiry protect a bundle on the network and against the page. They weren’t designed to protect it from someone who already controls the laptop, and nothing running inside a browser can be. Here is each case: what an attacker can do, what they can’t, and what closes the gap.

Reading, changing and forging a bundle

Reading the bundle off the diskHolds, with limits

They can: Anyone who can read the person’s browser profile can read the whole bundle as plain text. That’s the person, software running as them, an administrator, or anyone holding the disk of a laptop without disk encryption. They learn every rule, everyone’s allowlists, and every live exception with its value, approver and reason. The same storage holds the browser’s short-lived device token, the signed list of that person’s own groups, and any audit events not yet sent, which can include values a rule matched.
They can’t: Get shared-account passwords, authenticator setup keys or codes, or the signing key. None of them are there. Group memberships aren’t there either: a browser holds only its own person’s groups.
What to do: Full-disk encryption (FileVault, BitLocker) enforced by your MDM, and a short screen lock. Keep reasons for access requests plain. Bundles scoped to one person aren’t built.

Changing the stored bundleNot defended on that laptop

They can: Someone who can write to the profile’s extension storage can change the stored bundle: switch the emergency stop on, delete rules, add exceptions, stop genuine updates from replacing it, or change which person the browser thinks it belongs to. The browser doesn’t check signatures again on what it reads back. Those who can write there are software running as the person (for example while Chrome is closed), an administrator, and anyone using developer tools on the extension where they’re allowed.
They can’t: Affect any other laptop, change anything on LayerT’s servers, or approve anything in the console. The change stays on that one browser.
What to do: No local administrator rights for staff. Block developer tools for extensions and Chrome’s developer mode through policy. Run endpoint protection, and use your MDM’s compliance checks. Checking the stored bundle’s signature on every read isn’t built, and it wouldn’t stop an administrator, who can replace the extension itself.

Forging or altering a bundle in transitLayerT holds

They can: Nothing useful without the signing key.
They can’t: Get a browser to accept a bundle they made or changed. It fails the signature check, and a bundle signed with any other key is refused because the key isn’t built into the extension.
What to do: Nothing extra. This is what the signature is for.

Replaying an old bundleHolds, with limits

They can: Only in a narrow case: if the stored bundle is gone (for example, the browser re-enrolled or someone deleted it) and they control the connection, such as with an interception certificate an administrator installed, they could deliver a genuine, unexpired bundle from your organisation’s last 7 days.
They can’t: Replace a stored bundle with an older one. The version must go up. LayerT’s servers only ever serve the latest bundle.
What to do: No local administrator rights, and control over which root certificates your laptops trust.

Sending another organisation’s bundleLayerT holds

They can’t: Get it accepted. Every bundle’s organisation id is covered by its signature, and the browser refuses one that isn’t its own. The same check stops a genuine bundle from another LayerT customer.
What to do: Nothing extra.

Using an expired bundleHolds, with limits

They can: Keep an expired bundle current by setting the laptop’s clock back, because expiry is judged by the laptop’s clock.
They can’t: Deliver an expired bundle to a browser with a correct clock. It’s refused on arrival, and once the stored one expires, blocking rules fail closed.
What to do: Managed laptops don’t let staff change the clock. Keep it that way, and keep time synchronisation on.

The network and the web page

Blocking LayerT on the networkHolds, with limits

They can: Keep the browser on its last genuine bundle for up to 7 days, which delays new rules, new revocations and the emergency stop.
They can’t: Make the bundle more permissive, or avoid failing closed. When it expires, blocking rules stop submissions on the pages they cover until the browser reconnects.
What to do: The console’s coverage view flags browsers that haven’t been in touch for 3 days. It shows the version LayerT last sent to each browser, which isn’t proof the browser accepted it, so treat a silent browser as one to follow up.

A malicious web pageHolds, with limits

They can: Run its own scripts on its own pages, as any site can. Enforcement inside a page has limits of its own, listed on the Limits and open work page.
They can’t: Read or change the bundle or the extension’s storage, or send messages to the extension: it accepts none from websites. LayerT’s content script runs in an isolated world the page can’t reach, and its prompts are drawn in closed shadow roots.
What to do: Nothing extra for the bundle itself.

People and software on the laptop

Malware running as the personNot defended on that laptop

They can: Everything in reading and changing the bundle. It can also act as that browser towards LayerT while it runs on that laptop: copy the short-lived device token, and use the browser’s own key there to renew it. The key is protected by the browser’s software, not by hardware. So it can download your organisation’s bundle, send audit events, and fetch sign-in grants for that person’s own active shared-account sessions on that device.
They can’t: Fetch grants for other people or other devices, sign a bundle, or change anything in the console. A copy of the token alone stops working within minutes.
What to do: Endpoint protection, application control and your MDM’s compliance checks. When you suspect it, revoke the browser in the console and suspend the person in your identity provider.

Malware or a person with administrator rightsNot defended on that laptop

They can: Everything above, plus remove Chrome’s policies, uninstall or replace the extension, install a certificate that lets them read HTTPS traffic, and change the clock. A determined administrator on a laptop defeats LayerT on that laptop. No control running inside a browser can prevent that.
They can’t: Reach other laptops or LayerT’s signing key.
What to do: No local administrator rights for staff, and MDM with tamper protection. This is the most important control on this page.

A stolen laptop, unlockedHolds, with limits

They can: Whatever the person could do: use their access within your rules, and read the bundle from their profile without administrator rights.
They can’t: Do more than the person could, unless they also have administrator rights or can load modified extensions.
What to do: Revoke the browser in the console, suspend the person in your identity provider (their exceptions drop out of the next bundle), and lock or wipe the laptop through your MDM. A short screen lock keeps this case rare.

A stolen laptop, locked, with disk encryptionLayerT holds

They can’t: Read or change anything in the browser profile. The device token stops working within minutes, and renewing it needs the browser’s key, which is on the encrypted disk. There is no long-lived refresh credential.
What to do: Revoke the browser anyway. Without disk encryption, whoever holds the disk can read everything in the profile, and the browser’s key is protected by software, not by hardware, so revoke promptly.

Removing or switching off the extensionHolds, with limits

They can: On a browser where LayerT wasn’t force-installed, a person can switch it off or remove it. Other browsers, and Chrome profiles where LayerT isn’t set up, are outside LayerT altogether.
They can’t: Switch off or remove a force-installed extension through Chrome’s settings.
What to do: Force-install LayerT with your MDM. LayerT’s Chrome policy templates force-install and pin it, and turn off Incognito, Guest mode and Chrome’s own password manager. The signed extension package for force-install is built and ships with LayerT’s first production release. We also recommend setting Chrome’s developer-tools and developer-mode policies so nobody can load a modified copy. The console’s coverage view shows browsers where LayerT can be switched off, browsers that have gone silent, and browsers where it was removed.

Enrolment, revocation and LayerT itself

A copied device tokenHolds, with limits

They can: Act as that browser towards LayerT until the token expires, within minutes: download the organisation’s bundle, send audit events, and fetch grants for that person’s own active sessions on that device.
They can’t: Keep going once the token expires. Renewing it needs a proof signed by the key that browser made for itself, which can’t be exported through the browser, and there is no long-lived refresh credential to copy. A captured proof can’t be used again, and a captured sign-in response is useless without the key. They also can’t enrol a browser as somebody else: the identity a browser is bound to is signed by LayerT and checked when it enrols.
What to do: Revoke the browser. The key isn’t hardware-backed and this isn’t device attestation, so software running as the person on that laptop can still use the key there: see “Malware running as the person”. Disk encryption keeps the profile off a stolen disk.

A browser that isn’t yours to trustHolds, with limits

They can: Anyone who can sign in through your identity provider as one of your people can set LayerT up in a browser, on any machine. That browser then waits, and its popup says so.
They can’t: Get a bundle, the person’s groups or any shared account before an Owner or IT Admin approves the browser on Devices. LayerT’s servers refuse a waiting or declined browser, not only the extension. What the browser reports about how it was installed is its own word: it’s shown to the approver and decides nothing.
What to do: Approve only browsers you recognise, and decline the rest. Approval is a person’s decision, not proof that a device is company-owned or managed. An Owner or IT Admin can approve their own browser, and the audit log names the approver. The person whose account set the browser up isn’t told by email.

A revoked browserHolds, with limits

They can: Keep working as an ordinary browser. When you revoke it, LayerT publishes a bundle listing it. On its next sync, it stops enforcing rules and stops reporting. Its current device token works until it expires, within minutes. Its renewal is then refused, and it’s un-enrolled and doesn’t try again by itself.
They can’t: Receive policy, sign in to shared accounts or report to LayerT once it’s cut off.
What to do: Revoking cuts a browser off from LayerT. It doesn’t lock the browser, and a revoked browser enforces nothing. To stop a person, suspend them in your identity provider as well, and lock or wipe the laptop through your MDM.

A breach of LayerT’s serversHolds, with limits

They can: An attacker who controls LayerT’s application servers can ask the key service to sign, for as long as they keep that access. They could publish a permissive or hostile bundle for any organisation, and browsers would accept it. Someone with only the database can read every organisation’s bundles, which aren’t encrypted there, and can stop serving them.
They can’t: Copy the signing key out of the key service. With only the database, they can’t sign anything, and browsers refuse older versions, so withholding bundles leads to failing closed, not to old rules.
What to do: On LayerT’s side: only LayerT’s own services may use the key, and the key service logs every signing request. Removing the attacker’s access ends the window. Bundles already accepted stay until they’re replaced or expire, within 7 days. The same key signs for every organisation, so this case affects all of them.

Compromise of the signing keyHolds, with limits

They can: The key can’t be exported from the key service, so this means misusing it through the service, as above. If the key ever had to be replaced, anyone who could sign with it and deliver a bundle could make any browser accept that bundle until the replacement reached them.
They can’t: Use the key once LayerT has shipped an extension release without it.
What to do: Replacing the key needs a new extension release with the old key removed. Chrome usually rolls an update out within hours, or when the browser restarts.

What your IT team should set up

The bundle is only as trustworthy as the laptop it’s stored on. These are standard device-management controls, and LayerT relies on them:

Full-disk encryption, enforced by your MDM, and a short screen lock.
No local administrator rights for staff.
Force-install LayerT through your MDM, and use LayerT’s Chrome policy templates.
Approve new browsers promptly, and only the ones you recognise. Every new browser waits on Devices until an Owner or IT Admin approves it.
Block extension developer tools and developer mode through Chrome policy.
Keep other browsers and unmanaged Chrome profiles off work laptops, or accept that LayerT doesn’t see them.
Keep the clock synchronised and out of staff’s control.
Endpoint protection that can spot software tampering with browser profiles.
A leaver or lost-laptop routine that does three things together: revoke the browser in LayerT, suspend the person in your identity provider, and lock or wipe the laptop.
Watch the coverage view for browsers that have gone silent or can be switched off.

The limits, in one list

A bundle is checked when it arrives, not each time it’s read. Anyone who can write to the browser profile’s extension storage, or has administrator rights, can defeat enforcement on that laptop.
Every browser holds the whole organisation’s bundle, including other people’s allowlists and every live exception with its value, approver and reason. Bundles scoped to one person aren’t built.
A browser holds only its own person’s group memberships, as a signed answer valid for 24 hours. An offline browser keeps that answer until it expires, so a person taken out of a group can keep matching a group rule for up to 24 hours there.
Each browser’s key is protected by the browser’s software, not by hardware. It can’t be exported through the browser, but software running as the person can use it on that laptop. Scheduled rotation of that key isn’t built.
Approving a browser is a person’s decision. It doesn’t prove the device is company-owned or managed.
The bundle is stored as plain JSON. At rest, only the laptop’s disk encryption protects it.
Expiry is judged by the laptop’s clock.
Urgent bundles (emergency stop, rollback, revocation) arrive on the next page change or within 15 minutes, like any other.
Revoking a browser stops it enforcing and reporting. It doesn’t lock it.
The console shows the version LayerT last sent a browser, not proof the browser accepted it.
One signing key signs for every organisation. Replacing it needs an extension release.
The signing key is software-protected in the key service, not held in a hardware security module. Signing through a key service is built and in use in LayerT’s test environment. Production is not deployed.

What this page leaves out. This page describes the design and its limits. It doesn’t list individual defects before they’re fixed. If you find one, write to security@layert.net.