"Can't we add it after launch?" — mostly yes, except for five things
Raise security with a team two weeks from launch and the answer is usually some version of this: "Content is the crunch right now. We'll ship, see how it goes, and add it after."
That is a reasonable call. Most security work genuinely can be added later. Turning on detection modules, collecting logs, tightening policy — teams do all of that mid-service.
The problem is that a few things are mixed in that do not work that way. Some decisions harden the moment you submit the build, and changing them afterwards means shipping a new release or touching player data. Content is the right thing to be urgent about. But these five take thirty minutes to settle now and save weeks later.
This is not an article about choosing what to adopt. It covers only what gets expensive if you leave it undecided. For what to adopt first at your team's size, see the security guide for indie and small studios.
1. Scripting backend — shipping on Mono is hard to walk back
Unity's scripting backend changes the structure of the build output itself. Build with Mono and your C# stays as managed assemblies that a decompiler can open. IL2CPP converts it to a native binary.
Changing it is one setting. Changing it after launch is where the trouble starts. Build times and output size shift, and problems you never had before surface around native plugins, reflection and serialization. Not many teams have room to validate that mid-service.
None of which means IL2CPP is a cure. Metadata still ships, and tooling can reconstruct a great deal from it — we covered that in Is IL2CPP really secure?. The point here is narrower: decide which one you are using before launch, and finish validating on that setting.
2. Signing and package integrity — touching it later shakes your install base
App signing is less a security setting than an identity. Change the signature and, as far as the store and the device are concerned, it is a different app.
Android does offer a key upgrade path through Play App Signing, but the procedure is heavy and can affect users who already installed. What is worth confirming before launch is roughly this:
- Where the signing key lives and who can reach it is decided.
- The build pipeline signs with the same key every time.
- The baseline for judging whether a package has been tampered with is built into the build.
The third is the awkward one to add later. Identifying a repackaged build means knowing what a legitimate build should look like, and that baseline is produced at build time. The mechanics of repackaging are covered in the Unity MOD APK protection guide.
3. Where server authority is drawn — the latest to fix, and the priciest
This is the hardest of the five to change afterwards, because what is entangled is not code but data structures and player records.
The question worth answering before launch is this: "If this value is manipulated, does it affect other players or revenue?"
If so, the final say on that value belongs on the server — currency balances, whether a purchase was granted, ranking scores. Ship with the client calculating and the server merely recording, and moving to server authority later starts with deciding what to do about the records already accumulated. Separating manipulated values from legitimate ones after the fact is often not possible.
This is not a case for moving everything server-side. There is no reason for the server to adjudicate presentation values in single-player content. The point is to decide where the line sits before you launch. For a worked example on the save-data side, see game save file tampering.
4. What is left in the build — open it once before submitting
Some things were necessary during development and are a problem in a release build. Most teams know about them and miss them anyway under deadline.
- No development or staging server addresses remain in the build.
- Test accounts, cheat commands and debug menu entry points are removed.
- Debug symbols and verbose logging match the release configuration.
- No unused development libraries are bundled in the package.
- No server API keys or secrets are embedded in the client.
Only the last one behaves differently. The first four are done once you clean them up, but a secret shipped inside a client should be treated as already disclosed. The build sits on user devices, and strings inside it are eventually read. If you find one, what it needs is rotation, not deletion.
5. What happens after a detection — without policy, you decide it live
Turning detection on and acting on what it finds are two different jobs. And if you have not settled the second before launch, you will settle it at 3 a.m. during an actual incident.
Three things to decide:
- What action to take — record only, warn, or block. It can differ per detection.
- What happens on a false positive — whether there is a path to reverse it when a legitimate player is caught.
- Who decides — the line between automatic handling and human review.
Enabling blocking with no false-positive path is the riskiest combination in practice. Wrongly blocking a handful of legitimate players costs more than missing a handful of cheaters. Start by recording only, then raise the strength once you have data — that order is the safe one.
If you are still weighing how to adopt any of this, in-house versus commercial SDK is a useful comparison.
Final check before submission
The five above, gathered into one pass.
Build configuration
- The scripting backend is settled and QA finished on that setting.
- The signing key's storage location and access rights are decided.
- A baseline for detecting package tampering is included in the build.
Structure
- Values whose manipulation affects other players or revenue are adjudicated by the server.
- The line between client-decided and server-decided values is written down.
Build residue
- Development server addresses, test accounts and debug entry points are removed.
- No secrets are embedded in the client. If there were, they have been rotated.
Operational readiness
- Each detection has a decided action.
- There is a path to reverse a false positive.
- The team has agreed to start record-first.
If you are evaluating OZero Security
Of the five above, we help with parts of 1 and 2, and with 5. Check Setup points out a project that is not on IL2CPP and checks the Android signing certificate and manifest signing, and you choose what happens after a detection (log, callback or quit) in Response Settings. Numbers 3 and 4 belong to your game design, your backend and your release process, and we cannot stand in for them.
On adoption cost specifically: import the package (from Package Manager > My Assets for an Asset Store purchase, or as a .unitypackage from the customer portal) and the Welcome window opens. Check Setup lists what the project still needs, Auto Setup applies the recommended settings one confirmed step at a time, and modules are set in Project Settings > OZero Security. There is no need to edit scenes or change game logic. Even reviewed close to launch, it is a lighter lift than items 1 and 2.
The ordering does matter, though. The scripting backend and signing scheme need to be settled first for integrity verification on top of them to mean anything.
In closing: separate what can wait from what cannot
Approaching pre-launch security as "how much security have we got" has no end to it. No team ships in a complete state.
Sort it differently instead: what can be added later and what has to be settled now. The five here are the latter. The rest can wait until you have shipped and seen the response.
Next steps
- Check the protection scope — platform support and what each plan (Standard / Pro) defends.
- Start a quick integration — the import and configuration steps are in the integration guide.
- Talk to us — if your launch date is tight, ask what is achievable with your current setup.