Opens ready to search
The LayerT launcher opens from the toolbar with search focused. Each account has one button that does what it says.
Shared accounts
Share access, not passwords.
Your social accounts, vendor portals and finance logins, shared the way they should be. LayerT signs people in for them, so nobody needs to know the password, and the access ends on time.
Asking for an account, and signing in to ones that ask for more
Shared accounts
Share access, not passwords.
Sensitive accounts need an approver first, and every session ends on time.
Shared accountsAsk in place
Vendor Billing Admin needs an approver. Alice gives a reason and sees who decides and how long the session lasts.
Waiting on an approver
The request waits in the launcher and in the approver’s Inbox. Accounts that one person holds at a time say who has them.
Approved and signed in
LayerT signs Alice in without showing her the password. The session ends on time, and LayerT signs her out.
DemoThe LayerT launcher in the browser toolbar
Shared accounts
Sign-ins that ask for more.
Account IDs, company codes and PINs are filled too, and the team’s notes travel with the account.
Shared accountsAn account ID as well
Vendor Cloud asks for an account ID before the username and password. Alice picks the team’s account from the LayerT icon in the field.
LayerT fills every field
The account ID the owner saved, then the username and the password. The password never shows, and LayerT fills the authenticator code on the next screen.
Signed in, on a clock
The chip shows it’s a LayerT session and how long is left. When time runs out, LayerT signs her out.
Notes and the current code
The toolbar popup shows the account ID with Copy, the team’s pinned notes, and the current code with its countdown for whoever holds the session. Viewing the code is logged.
DemoA vendor sign-in with an extra field
Shared accounts
Codes a vendor emails, handled.
When a vendor emails a code to a team address, LayerT finds it and fills it in. Nobody needs the whole inbox to sign in.
Shared accountsThe vendor emails a code
Vendor Cloud doesn’t recognise Alice’s browser, so it emails a code to the team’s address, vendors@. Alice has never had access to that inbox.
Filled in seconds
LayerT reads the shared mailbox, read-only, finds the code a few seconds after it arrives and fills it in. Only mail that arrived during her own sign-in counts.
Only her sign-in email
The toolbar popup shows the code and where it came from, for whoever is signed in. Nothing else in the inbox is shown to her.
A reset goes to the owner
A password-reset or account-change email that arrives during her session is never shown to her. Bob, the account’s owner, sees it in his Inbox instead.
No new-device check next time
Bob keeps the vendor’s “remember this device” cookie, so the next sign-in skips the code. A test sign-in proves that keeping it still signs people out when their session ends.
DemoVendor Cloud asks to verify a new browser
Everything a team needs to share a login safely
- Sign in without seeing the password LayerT fills the vendor’s own sign-in form. The password isn’t shown in the launcher or saved in the browser. The only way to see it is a request that two people approve.
- Access by group, role or person Groups come from your directory. Change someone’s team in JumpCloud and their access follows.
- Approval when it matters Low, medium and high sensitivity. Medium and high need an approver by default. Nobody approves their own request.
- Sessions that end on time One hour by default, extendable up to eight. A minute before the end, people can extend or sign out. At the end, LayerT signs them out.
- One holder at a time For vendors that allow a single session. Everyone else sees who has it, and until when.
- Authenticator codes handled for you LayerT keeps the authenticator setup key on its servers and fills the current code. The person holding the session can also see the current code in the toolbar popup, with its countdown, and viewing it is logged. The setup key itself is shown only through a request that two people approve.
- Sign-ins that ask for more Account IDs, organisation IDs, company codes and PINs are filled along with the username and password. Secret fields only go into password boxes. If a site asks for a field nobody taught LayerT, it says so and can tell the account’s owner.
- Notes the team can read Pin notes such as “use region eu-west-1” to an account, and they show in the popup. Notes keep their author and history. A note that contains the account’s password is refused.
- A launcher in the toolbar Search, favourites and one button per account that does what it says: Sign in, Open or Request. Alt+Shift+L opens it.
- Set up by pointing LayerT detects the sign-in form or records the steps once. A test sign-in proves it works before anything submits automatically, and every recipe’s signature is checked before it runs. For some sites LayerT brings its own signed recipe, and the account’s Sign-in tab says which recipe is used.
- Sign-ins that span more than one address An account can list the other sites it uses, such as a separate sign-in address, one exact address per line. Where a site shows its sign-in form in a frame from another address of the same site, LayerT finds the form there, fills it and says on the page which address the form belongs to. A frame from an unrelated site is refused, a frame nobody can see is never filled, and LayerT never presses the sign-in button for a form in a frame.
- Sign-in health Each sign-in attempt reports how it went, with no values or page text. Sign-in health shows which sites need attention over 7, 30 or 90 days, in words such as “Couldn’t find the password box (step 3).”
- Offboarding in one step Deactivate someone in your directory and LayerT ends their sessions and requests everywhere.
- Seeing a password takes two approvals The account’s owner, an IT Admin or an Owner can ask, with a reason. Two other people approve, one of them an Owner or Compliance Officer. The requester sees it once, it’s marked as seen, and the owner is asked to change it.
- Told the moment a password is seen When someone views a password, Owners, Compliance Officers and the account’s owner hear straight away by email and in Slack.
- Codes a vendor emails to a shared inbox Connect a team mailbox, read-only. When a vendor emails a sign-in code, LayerT fills it in and shows it in the popup to whoever is signed in, a few seconds after it arrives. Nobody else’s mail is shown to them, and password-reset emails never are: the account’s owner is told instead. Owners can teach LayerT which senders send an account’s codes. Built. Switched off in production until LayerT’s compliance review, because LayerT then keeps a copy of that mail.
- Reading a shared mailbox, with approval When someone needs the whole inbox, they ask. Once approved, they read it in the console, read-only, for a set time. The page is watermarked with their name, every email they open is logged, links go through a warning page, and attachments are listed but can’t be downloaded unless you allow it.
- Fewer “new device” checks Keep a vendor’s “remember this device” cookie when a session ends, so people aren’t asked to verify every time. Everything else is still cleared, and LayerT only keeps the list once a test sign-in proves the person is still signed out afterwards.
For your security review
How it works underneath, written for the people who have to sign it off.
Put a layer on the browser.
LayerT is pre-launch and taking demo requests. Tell us what you want to solve, and we’ll show you the product doing it.
