I've been running Panther in a production environment for approximately nine months, following a proof-of-concept phase last year. My team's overall assessment aligns with the thread title: the core SIEM product itself is technically sound, particularly for organizations heavily invested in AWS and a cloud-native, infrastructure-as-code approach. However, the professional services engagement we undertook for the initial deployment was, frankly, a significant bottleneck that nearly derailed the project's ROI timeline.
Let me substantiate this with specifics from our implementation phase. We contracted Panther's services for what was billed as an "accelerated deployment" of their core platform, including initial log source onboarding (AWS CloudTrail, VPC Flow Logs, and our EKS control plane logs) and the creation of a dozen critical alerting rules. The deficiencies we encountered were multifaceted:
* **Lack of Deep Kubernetes & Cloud-Native Expertise:** The assigned solution architect was clearly versed in Panther's UI and basic AWS integrations, but struggled with the complexities of our EKS architecture. For example, when we requested assistance in structuring Panther to ingest container runtime threats via Falco, the proposed configuration was a generic, non-scalable sidecar deployment that ignored our use of DaemonSets. We ended up having to redesign the integration internally.
* **Formulaic, Non-Adaptive Workflows:** The service followed a rigid checklist that didn't account for our existing CI/CD pipelines or Terraform module structure. They provided Panther's standard Terraform modules without modification, which conflicted with our internal conventions for state management and environment separation (`prod` vs. `stage`). The resulting friction required us to re-engineer their provided code, negating the supposed time-saving value of the engagement.
* **Minimal Knowledge Transfer:** Sessions were focused on completing tasks rather than enabling our team. When we asked for detailed explanations on the security rationale behind default Python rule thresholds or the performance implications of different `datadog_enabled` configurations, we received superficial answers. The documentation handed over was essentially a copy of the public docs, with no organization-specific commentary.
The irony is that once we moved past the services hurdle and our internal platform engineering team took full ownership, the platform excelled. Writing custom detection rules in Python is straightforward, the auto-remediation workflows are powerful, and the cost predictability compared to legacy SIEMs is remarkable. The product works as advertised.
This creates a peculiar dichotomy. I would recommend Panther as a product, but with a strong caveat: budget for the license, but **do not** budget for their implementation services at the current maturity level. Instead, allocate those funds to an internal engineer or a third-party consultant with proven cloud-native SIEM experience. The implementation service, as it stands, seems optimized for the simplest possible use-cases and becomes a net negative for any organization with moderate complexity in its cloud environment.
-- alex