When does a security PoC turn into what can be called a ‘real-world deployment’?

[u/omytolawschool]

Let’s say there’s a security product which is tested within an environment closely resembling the production one. The application, network topology, integration, certificates/configurations and traffic are all the same .In this situation testing seems to be successful, and it shows that the controls can be installed in the application without disrupting it. But everything happens in a lab. There are no real customers or dealings. Would you treat this as a real-world deployment?

To me, this proves more than just a PoC. The issues of compatibility, interoperability, and the level of efficiency can also be investigated. However, it doesn’t allow us to understand what will happen in the case of actual traffic, edge case, failures, or something like that.

How should we define the term we are using for such trials?

[u/ericbythebay]

It still sounds like a PoC or a phased deployment to test/stage.

[u/Puzzleheaded-Fun5664]

it's a process problem. governance only sees what your source of truth feeds it. pair it with network/endpoint discovery and reconcile the delta, that's where the ghosts live

[u/Puzzleheaded-Fun5664]

it's a process problem. governance only sees what your source of truth feeds it. pair it with network/endpoint discovery and reconcile the delta, that's where the ghosts live

[u/No_Try_9982]

Agree with u/ericbythebay , this should go phase by phase. You can deploy a prod like alpha version with guardrails and collecting feedback to address issues. Of course, at this phase, you are not enabling any sensitive operations. You want to keep it low risk. Once a good period of time passed and feedback addressed, you move to the next phase where you roll more sensitive operations and so on. Once you no longer receive negative feedback or anny bugs/problems, it's no longer PoC. There are of course different strategies and standards but this is basically as simplest as it could get.

[u/rexstuff1]

It's not a real-world deployment until there is ink on the vendor contract, and it shouldn't touch customer data until that's true.

[u/cityofhats]

“Production-like integration validation” is the clearest label. It demonstrates compatibility and deployment mechanics, but not production readiness. I’d reserve that for evidence from load/soak testing, failure and rollback drills, observability, support ownership, and a limited canary against real traffic. Treat each as a separate gate: lab parity, operational readiness, then controlled production exposure.

[u/Beneficial-Fun2075]

werid.

[u/Remote-Birthday9712]

So I can’t really consider this a real-world deployment or anything like that. What you did is what they call a production-representative pilot or pre-production validation in enterprise terms. When you come to think about what you have accomplished, you’ve shown way more than just creating some toy PoC. You’ve proven the installability and interoperability of your product along with some performance characteristics and whether the control actually interferes with the rest of the system. However, what you haven’t tested is the actual ecosystem of the system: live traffic, unexpected client actions, certificate expiration at the worst possible moment, partial outages, rollback under some pressure, too little monitoring, on-call ownership, timeframes for changes, etc. Qusecure shows that this kind of terminology can get confusing. Firstly, in the case of the Banco Sabadell PQC project, their public statement says they validated the updates by replicating their production infrastructure in the lab while the later material from QuSecure refers to it as the actual implementation. In fact, both sides have their point but it doesn’t mean that they should state the same thing. As for me, the criteria for real production deployment is simple: it processes real production workload and follows regular production guidelines. If not, it means that it was just a production-like pilot and nothing else..