Backup products love to talk about peace of mind. This post does something different: it opens the hood. How does Beam Vault actually capture every change in an Okta org or Microsoft Entra ID tenant? Where do those versions live, who can touch them, and what exactly happens between clicking “Restore” and getting your environment back? 

If you’re evaluating identity backup — or just skeptical of anything that promises to un-delete the undeletable — this walkthrough covers the three engines that make Vault work and the six screens where you’ll use them. 

What Is Beam Vault? 

Beam Vault is a backup and point-in-time recovery add-on for Okta and Microsoft Entra ID, built into the Cyclotron Beam platform. It continuously captures the configuration state of your identity tenant — users, groups, applications, policies, and the relationships between them — into an independent, encrypted version store, and can restore any single object, set of objects, or tenant-wide configuration to a chosen point in time. It’s licensed per protected user in two tiers (Standard and Premium), and it lives in a dedicated Vault section of the Beam app alongside the migration platform it was born from. 

Under the hood, Vault is three engines in a trench coat: a capture engine that notices every change, a version store that keeps every state, and a restore engine that puts things back — in the right order, with the wiring intact. 

How Does Beam Vault Capture Changes? 

Vault captures changes continuously by listening to each platform’s change feed, rather than running nightly exports. The capture engine is event-driven and platform-native: 

A few design details do a lot of quiet work here: 

• Version-zero seeding. When Vault is enabled, it takes a full baseline of every covered object, so every version chain has a gap-free anchor — you’re protected from hour one, not from the first change. 
• Content-hash dedup. Every captured payload is hashed; if nothing actually changed, no new version is written. Your timeline shows real changes, not noise. 
• Provenance tagging. Every version records who kind of actor made the change — an external administrator, Beam’s own migration engine, a Vault restore, or a reconciliation sweep. This is the feature only a migration-native platform can offer honestly: because Beam knows exactly which writes it made, Vault can tell you which changes were yours, which were the project’s, and which were a surprise. 
• Three snapshot triggers. Beyond continuous capture, restore points are created on a schedule, on demand, and — automatically — before high-risk operations like a migration wave, a remediation run, or a policy push. The riskiest moments in an identity estate’s life get a safety net without anyone remembering to ask for one. 

Where Do Backups Live? 

Every version lives outside your tenant, in an append-only store encrypted per tenant — because a backup that shares its subject’s blast radius isn’t one. The storage design is deliberately boring in the best way: 

• Encrypted payloads in Azure Blob Storage, compressed (identity JSON compresses extremely well) and organized in per-tenant containers with lifecycle management. 
• Per-tenant envelope encryption. Each tenant gets its own data encryption key, which is itself wrapped by a key held in Azure Key Vault. No shared keys across customers, and key rotation happens without re-encrypting history. 
• A SQL catalog as the index — version chains, deletion tombstones, and the reference edges between objects (who’s a member of what, which policy targets which group). The catalog is what lets Vault answer “show me this group’s history” instantly and plan restores dependency-first. 
• An honest expiry policy. If your Vault subscription lapses, capture stops — but existing backups remain browsable and exportable through their retention window. Your data is not held hostage to a renewal. 

The platform carrying all of this is the same ISO 27001 certified foundation that runs Beam migrations, with every Vault action — every browse, diff, and restore — written to an immutable audit trail. 

What Happens When You Click Restore? 

A Vault restore is a planned, previewed, verified operation — not a blind write-back. The restore engine walks five steps: 

1. Scope. Pick a point in time and what to restore: one object, a selected set, or the whole tenant’s configuration. Scoped-and-surgical is the default posture — most incidents are a policy, a group, or a batch of attributes, not the world. 
2. Plan. Vault builds a dependency graph for the restore — users before groups, groups before memberships, apps before assignments, named locations before the policies that reference them — and maps old object IDs to their restored counterparts so every reference gets re-linked. On Entra, the planner checks the native recycle bin first: a soft-deleted object restored natively keeps its original ID and relationships, which skips re-linking entirely. On Okta — which has no undelete — the recreate-and-relink engine is the path, and the planner knows it. 
3. Preview. Every restore produces a dry-run diff before touching anything: exactly which objects will be created, updated, or re-linked, and what each change looks like. You choose the conflict policy — overwrite the live object in place, or restore as a new object for side-by-side validation. 
4. Approve. Role-based access control gates who can browse, diff, and restore; on the Premium tier, destructive restores can require four-eyes approval — a second administrator signs off before execution. 
5. Execute and verify. The restore runs as durable, ordered waves that survive interruptions, verify each wave before starting the next (both platforms are eventually consistent — freshly created objects take a moment to be referenceable), and adapt their write rate to your org’s real API limits. When it finishes, you get a verification report: what was restored, what was re-linked, what needs human follow-up. 

That last category matters, because some things no vendor can restore: passwords, multi-factor authentication (MFA) enrollments, client secrets, and certificate private keys are not exportable from either platform, by design. Vault’s restore flow flags them explicitly — a restored user needs to re-enroll MFA, a restored app needs regenerated secrets — instead of letting you discover it from help-desk tickets. 

What Do You Actually See in the App? 

Vault ships as six purpose-built surfaces in the Beam app: 

• Protection dashboard — coverage tiles, capture health, latest restore points, and any failures that need attention. The 30-second answer to “are we protected right now?” 
• Backup browser — search any object, open its version timeline, and see every change with its provenance badge. Side-by-side diff of any two versions shows exactly what changed, attribute by attribute. 
• Restore wizard — the five-step flow above: scope, conflict policy, dry-run diff, approval, execution with live progress and a downloadable verification report. 
• Settings — snapshot schedules, retention, dedicated capture credentials, and a beta-endpoints toggle (with a live availability probe) for teams that want Entra’s beta Conditional Access restore path, with a safe v1.0 fallback when it’s off. 
• Activity view — every Vault operation in one auditable stream, with drill-in detail drawers. 
• Failure alerts — email notifications when capture or restore jobs need a human, so protection failures never rely on someone checking a dashboard. 

What’s the Difference Between Standard and Premium? 

Capture runs continuously for every Vault tenant — the tiers differ in how much of that timeline you can use and which controls are enabled: 

The honest takeaway on recovery speed, whichever tier you choose: scoped restores complete in minutes; full-tenant recovery is bounded by Okta’s and Microsoft’s API rate limits — hours at enterprise scale, and Vault’s guidance documents that math instead of hiding it. 

Why Build Backup Into a Migration Platform? 

Because migration is where the discipline came from — and where the safety net matters most. Moving an identity estate between platforms is the highest-stakes change an identity team ever makes, and Beam’s migration engine already had to master continuous tenant capture, dependency graphs, staged execution, and rollback at enterprise scale. Vault generalizes that machinery into always-on protection: automatic snapshots before every migration wave, rollback insurance during the project, and change attribution that can tell a migration write from an admin edit — then keeps protecting the tenant long after the migration is done. 

Frequently Asked Questions 

What does Beam Vault back up? Users (profiles, managers, custom attributes), groups with memberships and owners, group rules and dynamic membership rules, applications and service principals with SSO configuration and assignments, Conditional Access policies and named locations (Entra), sign-on/password/MFA-enrollment/access policies and rules, network zones and trusted origins (Okta) — captured continuously with full version history. 

How current are the backups? Capture is continuous on every tier. Premium exposes the full timeline with restore points minutes apart — targeting a 15-minute-or-better RPO — while Standard provides daily restore points plus manual snapshots on demand. 

Can Beam Vault restore passwords or MFA enrollments? No — and neither can anyone else: credentials, MFA registrations, secrets, and private keys are not exportable from Okta or Entra ID by design. Vault flags these in every restore plan and gives you the re-enrollment and regeneration steps instead of hiding them. 

Does a restore overwrite my live configuration? Only if you tell it to. Every restore starts with a dry-run diff showing exactly what will change; you choose between overwriting in place or restoring as a new object, and Premium tenants can require a second approver before execution. 

Is my backup data safe if Beam is compromised? Vault stores versions in per-tenant containers with per-tenant envelope encryption — keys wrapped in Azure Key Vault, no shared keys across customers — with role-gated access and an immutable audit log of every access, on an ISO 27001 certified platform. 

What happens if we cancel the subscription? Capture and restore stop, but existing backups remain browsable and exportable through their retention window. Your history is never held hostage. 

See the Three Engines Run 

Capture that never sleeps, a version store nothing shares, and restores that plan before they write — that’s the whole trick, and it’s more engineering than magic. The best way to evaluate it is to watch it work on a real tenant. 

Get in touch for a Beam Vault demo — bring your hardest “could you restore this?” question.