As enterprise systems grow more automated and interconnected, cybersecurity is no longer just a matter of defending the perimeter. For Pega, a maker of low-code process automation tools used across regulated industries, security is a question of balance—between openness and control, speed and stability, autonomy and oversight. And that balance, according to Chief Cloud Officer Frank Guerrera, comes with a catch: the tools are there, but the responsibility isn’t shared equally.
“We support SAML (Security Assertion Markup Language) integration for clients to choose their own authentication mechanisms, including Okta,” Guerrera says. In other words, clients can plug Pega into their own identity and access setups. But who gets access to what? That’s not something Pega decides. “As part of the shared responsibility model, clients must define appropriate policies for managing access permissions in systems, such as RBAC (Role-Based Access Control) and ABAC (Attribute-Based Access Control).”
This hands-off stance isn’t a loophole—it’s a core design choice. Pega gives customers the infrastructure and security scaffolding, but not the rules. It’s up to each client to define boundaries and monitor who crosses them. Misconfigured roles or delegated privileges that grant too much power? Pega won’t block those outright. It simply expects clients to use the provided tools correctly.
Open by design, and that’s a risk
Pega’s strength lies in how well it connects with everything else. APIs, REST endpoints, integrations—these are central to how companies build and scale with Pega. But they’re also where the platform could be most exposed. Could attackers slip through a connector and into core systems? Guerrera says that while the potential is real, the risk is actively managed. “Pega engages third parties to conduct penetration testing of its products to identify unique vulnerabilities that must be remediated.” Those tests are run annually on key components like Infinity and the DX API, and help keep up with shifting threats, especially in custom deployments.
What about the decisioning engines that now drive more and more of the automation—Customer Decision Hub, Process AI, and so on? Pega doesn’t let these agents operate freely. “Pega anchors its agents in workflows that prescribe how they should act at runtime,” Guerrera explains. This is the logic behind the company’s “Agentic Process Fabric”: decisioning that’s automated, but always framed by business rules and traceable outcomes. The agents don’t learn in the wild; they execute pre-approved logic embedded in workflows.
Security that suggests, not enforces
When it comes to classic application security—cross-site scripting, SQL injection, CSRF (Cross-Site Request Forgery) – Pega offers baked-in protections. Secure coding, token validation, and role-based access controls are all part of the platform. But those protections aren’t absolute. “Guardrails” is the word Guerrera returns to: they guide developers toward safer patterns, but don’t force compliance. A team can still build something insecure—Pega won’t stop them.
Encryption is more stringent. Case data, attachments, and logs are protected with AES-256 encryption at rest and TLS 1.2 or 1.3 in transit. Clients also get options like BYOK—Bring Your Own Key—for full control over encryption keys, which is crucial for organizations governed by regional data laws or compliance mandates.
The attack surface only gets broader with mobile apps. Guerrera says Pega doesn’t cut corners here either. “Pega Mobile pen testing is conducted annually.” But even with tested code, the usual caveats apply: customers are still on the hook for enforcing device policies, managing local storage, and blocking compromised endpoints.
Then there’s the question of internal misuse. Rogue users reassigning cases, manipulating data, or tweaking workflows? “Clients configure RBAC/ABAC rules to ensure functions are appropriately segregated,” Guerrera explains. Pega provides detailed audit logs for accountability, but real-time protection requires clients to implement controls properly. After-the-fact logging is only useful if preventive measures were in place before something went wrong.
Zero-days and fast patching
When critical vulnerabilities, such as zero-day threats, emerge, Pega moves quickly. “Pega targets mitigation of critical threats in 4 hours and aims to fully remediate critical vulnerabilities within 7 days,” Guerrera explains. Customers are notified through the MySupport Portal, but they still need to be paying attention and ready to act. Pega can push patches, but it can’t make clients apply them.
For clients using Pega Cloud, there’s an extra layer of monitoring. The Cloud SOC scans for anomalies—data exports, suspicious API calls, lateral movement—and pushes alerts into Pega’s SIEM for further analysis. Still, Pega doesn’t manage incident response on behalf of the customer. “Clients are ultimately responsible for tying those alerts into incident response playbooks,” Guerrera says.
The thread running through all of this is clear: Pega believes in empowering its customers to secure themselves. The platform is secure by design, but not closed. It encourages best practices, but doesn’t mandate them. It monitors and tests, but leaves enforcement and governance to the customer. “Pega provides the architecture,” Guerrera says. “But customers must own the governance.”
In a way, that makes Pega’s model more realistic. It acknowledges that no platform can anticipate every configuration or every potential misuse. What it offers instead is visibility, tooling, and structure – and a firm expectation that customers will take full advantage of them.
