NewResilience, Continuity, the Pro levels and Agentic Verification: from safekeeping to proof you can recover.The new line-up is here.See what's new
Why this page looks like this. Production's /credentials-escrow opens with "Guarantee your software continuity" and closes with "Never lose access to critical services" and "guaranteed service continuity". All three are gone. Credentials can sit in any deposit (the SaaS escrow page lists credentials and access), but their main job is in Continuity, so Continuity is shown as the natural fit, in its agreed wording. This page touches security, so it states only the confirmed facts (AES-256 at rest, TLS in transit, ISO/IEC 27001:2022) and production's own lines on scope and use, flagged below. No encryption detail beyond that and no retention period.
  • One template for all eight "What we deposit" pages, as production has: hero, why it matters for recovery, what's included, how it gets in and how it's proven, which protection fits, the other seven materials, the evidence pack, FAQ and close. Every page follows the same fictional SaaS application, Booking Hub (also on the SaaS escrow page), so the set reads as one story: one application needs several kinds of material to come back.
  • Headline: keeps the search phrase and says what credentials are for in a recovery, without promising continuity.
  • Visual: a mock of what this part of the deposit holds. Production's hero image couldn't be opened from the kit to check it for old product names, so it isn't reused; swap it back only after someone has checked it.
  • Dropped: "Book a free demo" (now Book a demo), the closing line "Let's build bulletproof software resilience together", the press quotes with publication logos (Product Hunt and two others; not customer reviews, and the logos need permission), the third-party tool logos, the per-page e-book block (the sample evidence pack band replaces it) and "Unlimited automated deposits", the 1Password, NordPass, Keeper, LastPass and Dashlane logos ("Pick your platform, we'll integrate": password manager integrations aren't confirmed), "Protect revenue by preventing service-related downtime" and "start at $415 per month".
What we deposit

Credentials escrow. The access a recovery depends on.

Hosting, cloud consoles, billing portals and the services an application calls all sit behind a login. Codekeeper holds the credentials and keys needed to manage them, encrypted and used only as your agreement sets out.

Book a demo Get the sample evidence pack

Continuity from $1,449. Per application per month. Credentials can be part of any deposit.

  • Trusted by 3,500+ teams
  • ISO/IEC 27001:2022 certified
  • AES-256 encryption at rest
Social proof straight after the promise. These are the logos production already uses, loaded from codekeeper.co. Where an image can't load (for example in the preview), the name shows instead. Use the approved set only.

Trusted by 3,500+ teams, from regulated enterprises to fast-growing software vendors

Airbus Bayer European Parliament General Motors Intuit Nestlé PepsiCo Pfizer
Steps 1 and 2: the exposure and the shift, for credentials. Production asks "How do you prevent renewals or subscriptions from lapsing during disruption?" and says services "must remain accessible at all times". Here the exposure is the plain fact behind it: a deposit is only usable if someone can sign in to where the application runs. The right-hand column is confirmed facts (encryption) and the agreed Continuity wording. Production claim to confirm: that Continuity uses the access we hold to keep accounts paid ("Codekeeper can use escrowed billing credentials to process renewals"). The page says the access is "part of how" we keep the environment paid and switched on, and that it's agreed at setup.

Why it matters for recovery

A deposit is only usable if someone can sign in.

Code, data and configuration bring an application back only if someone can reach where it runs. If the vendor stops, the logins, billing roles and keys for its hosting and services can be lost with it, and a lapsed bill can switch the live service off.

Access held by one team

  • Admin and billing logins known to a few people at the vendor
  • Keys and MFA backups that can't be recovered
  • Renewals that lapse because nobody can sign in

Credentials with Codekeeper

  • The access a recovery needs, agreed and deposited at setup
  • Encrypted at rest with AES-256 and in transit with TLS
  • With Continuity, part of how we keep the live environment paid and switched on for an agreed period
Step 3 in detail: what a credentials deposit holds. The groups are production's FAQ list ("hosting platform logins, cloud console access, billing portal credentials, subscription management roles, API keys") and its key-escrow answer ("MFA backups, SSH keys, API keys, and signing keys"). Production capability claims to confirm: key escrow as listed; "used only when the conditions are met" (production: "activates them only when a contract-defined continuity event is confirmed"); adding Codekeeper as a separate billing user or role where a provider supports it. The callout states only confirmed security facts plus those flagged lines. Also to confirm: what the automated check and vault report show for credentials (that they're present, never the secret itself). Production's "Codekeeper captures updates automatically so the escrowed credentials always reflect your current setup" is left out until product confirms how credential updates work.

What's included

What a credentials deposit holds.

At setup, we list with you the providers in scope and agree the access we hold. For most applications, that means:

  • Hosting and cloud console access. Admin logins or roles for the platforms the application runs on.
  • Billing access. Billing portal logins or a billing-user role for each provider.
  • Service access. Logins and API keys for the third-party services the application calls.
  • Keys. SSH keys, signing keys and MFA backup codes, where they're needed to manage an account.
Usually part of
SaaS deposits, and Continuity
How it gets in
Deposited at setup, or added as a dedicated user
How it's held
AES-256 at rest, TLS in transit
Natural fit
Continuity
How credentials are held. Like every deposit, they're encrypted at rest with AES-256 and in transit with TLS, and Codekeeper is ISO/IEC 27001:2022 certified. We agree with you at setup which access we hold, and use it only as your agreement or arrangement sets out.
Steps 3 and 4: from setup to proof. Credentials don't sync through repository integrations the way code does, so the steps start with scope and a secure deposit, using production's own steps ("add billing users, generate access, or submit your credentials through encrypted channels"), flagged above. The map review is the confirmed Continuity process. "A rebuild doesn't reach your live systems" follows from the confirmed sealed Verification Lab (cut off from production, development and the open internet). The proof steps are confirmed facts: an automated check with a vault report and a Software Resilience Certificate with every protection; on Escrow Pro, Resilience Pro and Continuity Pro, Agentic Verification (the Codekeeper AI Verification Lab, no vendor help, hours, missing items flagged, monitoring between runs). The ladder is the agreed proof ladder, kept short; its last line keeps the agreed wording on release rights. 16 Oct: Continuity Pro added; base Continuity no longer includes Agentic Verification, so the map is reviewed with each rebuild only on Continuity Pro, and the example screen (which shows a rebuild) is labelled Continuity Pro.

How it gets in, and how it's proven

Agreed at setup. Held securely. Kept current.

Credentials are scoped with you, deposited through a secure flow and reviewed as the environment changes.

1

Agree what's in scope

At setup, we list with you the providers the application depends on and agree the access we hold.

2

Deposit securely

Where a provider supports it, add Codekeeper as a separate user with a billing or admin role. Otherwise, submit credentials and keys through the secure deposit flow.

3

Checked and certified

An automated check confirms what's in the deposit, with a vault report, and you receive a Software Resilience Certificate.

4

Kept current with the map

With Continuity, we review the live environment map when the deposit changes (with Continuity Pro, also with each rebuild), so changes to the accounts it depends on are picked up. Rebuilds run in the Codekeeper AI Verification Lab and don't reach your live systems.

Escrow · Resilience · Continuity

Software Resilience Certificate

The credentials are held with the rest of the deposit, and an automated check confirms what's there, with a vault report.

Proves: it's there.

Escrow Pro · Resilience Pro · Continuity Pro

Recoverability Certificate

AI agents rebuild the application from the deposit in the Codekeeper AI Verification Lab, with no help from the vendor, in hours. You also get the run report, an SBOM and an Exit workbook.

Proves: it builds. Agentic Verification

Add-on to any plan

Tested Exit Report

Our specialists rebuild by hand in a clean room and test the business functions you nominate, without the original developers.

Proves: you could exit and keep working. Exit Exercise

The higher you go, the more it proves. The Recoverability Certificate documents the rebuild; release rights come from the agreement. How verification works

Step 3 continued: Continuity is the natural fit, so its card is outlined. The three-job cards appear on every deposit page, each with one line on what that job means for this material on the day it's needed. The "from" prices are the 6 Oct list (Software row); the lead is the price logic sentence, word for word. With Escrow, credentials in the deposit are released under the agreement's release conditions; with Resilience, we use them in the recovery. The Continuity card is the agreed wording plus the flagged production line on how the access is used. No uptime, duration or hands-on operation is mentioned. 16 Oct: Continuity Pro added (from $1,699, setup $999) to the fine print; base Continuity no longer includes Agentic Verification. 17 Oct: the recovery models are named, as in the launch film (Danny): Self-Run Recovery for Escrow, Managed Recovery for Resilience and Continuity.

Which protection fits

Choose who uses the access, and when.

Escrow means the deposit is released to you and you run the recovery. Resilience costs more because we do the recovery. Continuity costs more again because we also keep the live environment switched on.

Released to you

Escrow

Released to you→Self-Run Recovery

Credentials in the deposit are released to you with the rest of it, under the agreement's release conditions. Explore Escrow

From $199

Recovered by us

Resilience

Comes to us→Managed Recovery

They come to Codekeeper, and we use them in the recovery we run for you. Explore Resilience

From $399

The natural fit

Continuity

Live service kept on+Managed Recovery

We agree the access we hold at setup. If the vendor stops, it's part of how we keep the live environment paid and switched on for an agreed period while we recover. Explore Continuity

From $1,449

Software list prices, per application per month; SaaS and AI have their own rows. Escrow Pro (from $449), Resilience Pro (from $649) and Continuity Pro (from $1,699) add Agentic Verification. Setup is $499 per arrangement, or $999 for Continuity and Continuity Pro. See all prices

Close the loop on the story: one application, eight kinds of material. Production's "Cover your full software infrastructure" block links to only two to five of the other asset pages, and files them under three old products (Software, SaaS and Continuity Escrow). Here all eight appear in the same order on every page, with this one marked, because one application usually needs several of them to come back. The order follows a recovery: what it's built from, how it's built, what it runs on, how to run it, what it calls, the thinking behind it, where it runs and the keys to it. The names match the footer. The links underneath go to the application pages, which say which materials each application type usually deposits, and to the guides hub instead of production's per-page e-book block.

Everything else we deposit

One application. Eight kinds of material.

An application usually needs more than one of these to come back. The agreement lists which ones your deposit holds, and they're checked together.

Source code

The codebase, scripts and libraries the application is built from.

Source code escrow

Deployment assets

Build scripts, pipelines and infrastructure definitions that turn code into a running system.

Deployment assets escrow

Data

Database exports, reference data and the files the application needs to work.

Data escrow

Documents

Installation guides, architecture and runbooks: how to build, run and support it.

Document escrow

Third-party dependencies

What it takes to maintain or replace the services and packages it relies on.

Third-party dependencies escrow

IP and designs

The designs, diagrams, algorithms and research behind the application.

IP escrow

Hosting environment

Where it runs and the accounts it depends on, mapped and kept current.

Hosting environment escrow

Credentials

The logins, billing roles and keys needed to manage where it runs.

You're on this page
What a software deposit holds What a SaaS deposit holds What an AI deposit holds Guides and case studies
The secondary conversion, on every page. Visitors who aren't ready to talk can still leave their email. The sample evidence pack is the same offer on every page, so the site has one lead magnet instead of a different e-book per page. It also carries the launch story: proof, not promises. The button goes to the sample evidence pack page.

Sample evidence pack

See what your auditor would receive.

An anonymised set of outputs from a real Agentic Verification run, so you can judge the evidence before you talk to us.

  • Recoverability Certificate
  • Run report
  • SBOM and Exit workbook excerpts
Get the sample evidence pack
The security questions first, then the practical ones. Kept from production: what it is, what can be deposited, and key escrow (production's answer, reworded and flagged). The protection answer states only confirmed facts plus the flagged "use it only as your agreement sets out". New: whether customers must share their own passwords, using production's "add billing users, generate access". Removed: "Continuity Escrow plans start at $415 per month", "ISO 27001–aligned environments" and "guaranteed service continuity". Legal and security should review all five answers.

Questions

Credentials escrow, answered.

What is credentials escrow?

An agreement in which a software provider deposits the logins, billing access and keys needed to manage the platforms and services its application runs on, with a neutral party such as Codekeeper. They're held under the agreement and used only when its conditions are met.

What can be deposited?

Hosting platform logins, cloud console access, billing portal credentials, subscription management roles and API keys, plus SSH keys, signing keys and MFA backup codes where they're needed to manage an account. The agreement defines exactly what's included.

How are credentials protected?

Like every deposit, they're encrypted at rest with AES-256 and in transit with TLS, and Codekeeper is ISO/IEC 27001:2022 certified. We agree with you at setup which access we hold, and use it only as your agreement or arrangement sets out. See the Trust Center.

Do we have to share our own passwords?

Not always. Where a provider supports it, you can add Codekeeper as a separate user with a billing or admin role instead. We go through each provider with you at setup.

Is key escrow included?

Yes, where keys are needed to manage or access the provider accounts: API keys, SSH keys, signing keys and MFA backup codes. They're held under the same controls and release conditions as the rest of the deposit.

The same close on every page. The close repeats the headline's idea and points to Continuity, where credentials do most of their work. Every page ends on the same two actions in the same order: Book a demo, then the sample evidence pack.

Keep the access a recovery needs.

We'll go through the accounts behind your application and what Continuity would hold.

Book a demoGet the sample evidence pack
Chat widget goes here. Production runs HubSpot chat in this corner. Keep it on launch: it catches visitors with a quick question who won't book a demo yet. Route it to sales during office hours.