This might be the most fun you ever have learning risk management.
Here is what I love about cybersecurity: the same concepts show up everywhere, and it is fascinating to watch them play out in different environments, especially when you get to read it from experts like Tim.
This guest post is a perfect example. It takes the exact ideas you are studying for GRC and CISSP, residual risk, risk treatment, threat modeling, impact versus likelihood, and shows them running live inside the gaming industry.
Real cheaters, real stolen revenue, real players walking away. Same framework you are learning for exams, such as CISSP, but with way better stories than any textbook.
So who better to walk you through it than someone who does this for a living? This post comes from Tim Uhlott, founder of GuardingPearSoftware, who has protected 4,000+ games since 2017.
Over to Tim.
Do you want us to collaborate more with Tim? Let us know in the comments!
You cannot make a game unhackable. Here is what “good enough” security actually means.
You finish a build. You ship it. Then a thought shows up that nobody put in the design doc.
Can I make my game totally unhackable?
I hear that question a lot from game developers who are just starting to care about security. It sounds responsible. It also points you at the wrong target.
Short answer: no. You cannot make a game unhackable. That is normal. The game runs on a computer or phone that the player owns. If someone has the device, they can look at files and change memory. They can replay traffic too. Perfect protection is not available on hardware you do not control.
The useful question is different. What is worth protecting, and what risk can you live with?
Here is what you will learn in this article:
Why “unhackable” is the wrong goal
Why a common cheat can matter less than a rare failure
Why single-player and multiplayer need different decisions
What economic protection actually means
How security people treat leftover risk on purpose
If you build games and you are new to cybersecurity, this is the shift that will save you months.
Do you find this article interesting? Subscribe to GuardingPearSoftware and learn something new about cybersecurity in the gaming industry every week.
The player owns the device
A game client is not a vault. It is software sitting on someone else’s machine.
That person can open the install folder. They can attach tools while the game is running. They can change a value in memory and see if the health bar moves. They can send the same “I won” message twice. None of this requires a movie-hacker setup. A lot of it is boring, documented, and shared in public.
So when your game checks a score on the device, or unlocks a sword because a local file says so, you are asking the player to be honest. Some will be. Some will not.
Client-side checks still have a job. They stop curious players. They slow down copy-paste scripts. They are a speed bump. They are not a wall.
Remember: The most dangerous system is not the one without anti-cheat. It is the one that believes the player’s device.
If one idea from this article sticks, make it that one.
Threat is not the same as impact
New security people often rank problems by how scary they sound. Infinite health feels urgent. A missing backend check on a purchase feels like paperwork.
Impact asks a different question. If this works, who gets hurt?
A cheat can be common and still be a shrug. A failure can be rare and still close a live game.
Takeaway: spend time where impact is high, not where the scare story is loud.
Note: Security professionals split this into likelihood and impact. A risk is not “this can happen.” A risk is “this can happen, and here is the damage if it does.”
If you only remember the table, remember the last two rows. Those are the ones that surprise studios.
If this changed how you think about risk, hit like and pass it on.
Single-player and multiplayer are not the same problem
The same word, “hacked,” hides two different jobs.
In an offline single-player game, a person who gives themselves infinite gold mostly hurts themselves. You might still care about piracy, copied art, or a paid unlock that never went through a store. Gameplay cheats are usually not your first problem.
In a multiplayer game, one modified client changes everyone else’s night. Fake damage, wallhacks, and invented currency do not stay on one machine. They show up as unfair matches and empty queues. The store stops making sense.
Purchases sit in the same bucket. If the device says “the store charged the card” and your game believes it, you did not sell an item. You accepted a story.
This is threat modeling, without the textbook first. You list what an attacker wants, who gets hurt, and which system is allowed to decide the truth.
Remember: The hack did not change. The owner of the harm did.
Ask “who pays if this works?” before you ask “how do I block every tool?”
Make cheap attacks expensive
Attackers are not a single villain with unlimited time. Most of them are people, or scripts, looking for a reward that is worth the evening.
If a leaderboard can be faked in ten minutes, someone will fake it. If inventing currency takes a week of ugly work and the reward is a hat, most people move on. Security people call this economic protection. You raise the cost of the attack until it is no longer a good deal.
You will not stop the most dedicated person on earth. That person is not your planning target. Casual edits and public copy-paste kits are.
Good enough security is not a fortress. It is a set of decisions that makes the cheap attacks annoying and the expensive attacks rare.
Remember: Good enough security makes the cheap attacks expensive and the expensive attacks rare.
That is a much kinder goal than “nobody can ever touch this.”
Subscribe to GuardingPearSoftware for practical game security every week.
Leftover risk is not a failure
Some things you cannot prevent, because the player owns the device.
You cannot stop someone from reading memory on their own PC. You cannot fully stop software that aims by looking at the screen. You cannot hide every secret forever if that secret ships inside the app. A person with enough time can study a client.
That leftover piece has a name: residual risk. It is the risk that remains after you have done the work you chose to do. Naming it helps you stop chasing a clean score of zero.
Security people then pick a treatment. They do not hope the leftover risk disappears.
Accept it. Infinite gold in a paid offline game can stay in the “we know, we are fine” pile.
Mitigate it. Put rewards, purchases, and match results on a server you control. Make the shipped code harder to read. Watch for progress that cannot happen in a real session.
Transfer it. Let the store confirm a receipt. Let Steam, Apple, or Google confirm that a session belongs to a real owner. Let a host or protection service take the first hit when traffic tries to knock the game over.
Avoid it. If you cannot put the truth on a server, do not ship ranked mode, player trading, or a real-money economy. That is not cowardice. That is choosing not to create a problem you cannot own.
Note: This set is called risk treatment: accept, mitigate, transfer, avoid. The grown-up move is choosing one of the four on purpose, not hoping for zero risk.
If you skip the choice, you still made one. You accepted the risk by accident.
If this made you feel better about a risk you cannot remove, give it a like.
A simple order of work
You do not need a security team to start. You need a short sequence you can repeat.
First, name the game you actually shipped. Offline single-player, online with scores, competitive, or something that sells items for real money. The type changes every later choice.
Second, write down what would actually hurt. Stolen revenue. Other players leaving. Keys that open a backend. A public board that looks fake. If a problem is not on that list, it can wait.
Third, move the painful decisions off the device. The client can send input. It can show animations. It should not be the judge of rewards, inventory, match outcomes, or purchases.
Fourth, accept the rest out loud. Write it down if you have to. “Players can cheat their own offline save. We are okay with that.” That sentence is a control. It stops you from spending a month on a lock nobody needed.
Fifth, ship, then look again when the game’s value changes. A quiet hobby project that later adds trading is a new game from a risk point of view. The old accept list may be wrong now.
What game are you building, and which row in the table above is the one that would actually hurt you? Tell me in the comments. I am curious where people draw the line.
Saving these steps for the future? Hit the like button and help other people find it.
Key takeaways
Unhackable is not a goal. The player owns the device, so leftover risk will always exist.
Impact beats fear. A common cheat can be cheap to ignore. A rare failure can be expensive.
Game type changes the model. Offline cheats and live-service cheats are not the same job.
Raise the cost. Make casual and automated attacks a bad use of time.
Treat leftover risk on purpose. Accept, mitigate, transfer, or avoid. Do not drift.
Master those five, and you will stop asking “is this bulletproof?” You will start asking “what fails, who pays, and which treatment did I pick?”
That is how security people think. It is also how you keep building games instead of rebuilding the same lock.
If these five stuck, hit the like button so the next dev gets the short version instead of learning it the hard way.
The question was the trap
Go back to the start. “Can I make this unhackable?”
If you chase yes, you delay the release, and you still fail. The device is not yours. The dedicated attacker still exists. The month you spent on a perfect client check was a month you did not spend on the server decision that actually mattered.
Good enough security is a clear risk choice. It protects the money and the other players. It also protects the secrets. It leaves the rest alone on purpose.
That is not giving up. That is how you ship.
About the author
I am Tim Uhlott. I started coding at 12 because I wanted to know how games worked, and I still like taking a messy problem apart until the real decision shows up.
That is the work I do now at GuardingPearSoftware. I teach cybersecurity for games and I build security tools for Unity developers who are trying to protect the parts that actually matter.
If you want more of this, you can find me here.
Let’s Connect
If you want to collaborate, discuss, or just geek out over networking and cybersecurity, reach out:
Email: erich.winkler@decodedsecurity.com
LinkedIn: Erich Winkler
Gumroad community: Decoded Security
Start Here: Decoded Security Roadmap
Enjoyed this article? Like it or drop a comment. I’d love to hear your thoughts and questions!
Let’s learn and grow together!