<?xml version="1.0" encoding="UTF-8"?>        <rss version="2.0"
             xmlns:atom="http://www.w3.org/2005/Atom"
             xmlns:dc="http://purl.org/dc/elements/1.1/"
             xmlns:sy="http://purl.org/rss/1.0/modules/syndication/"
             xmlns:admin="http://webns.net/mvcb/"
             xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"
             xmlns:content="http://purl.org/rss/1.0/modules/content/">
        <channel>
            <title>
									CyberArk Reviews - Welcome to Stackinsight community. Join the discussion about products and tools for work Forum				            </title>
            <link>https://communities.stackinsight.net/community/cyber-cyberark/</link>
            <description>Welcome to Stackinsight community. Join the discussion about products and tools for work Discussion Board</description>
            <language>en-US</language>
            <lastBuildDate>Sat, 14 Nov 2026 08:02:26 +0000</lastBuildDate>
            <generator>wpForo</generator>
            <ttl>60</ttl>
							                    <item>
                        <title>Showcase: I scripted a way to reconcile CyberArk safes with our CMDB nightly.</title>
                        <link>https://communities.stackinsight.net/community/cyber-cyberark/showcase-i-scripted-a-way-to-reconcile-cyberark-safes-with-our-cmdb-nightly/</link>
                        <pubDate>Mon, 28 Sep 2026 04:06:10 +0000</pubDate>
                        <description><![CDATA[Hey everyone! I&#039;ve been lurking for a bit while we rolled out CyberArk, and I&#039;m still wrapping my head around all the concepts. Something our security team mentioned early on was the importa...]]></description>
                        <content:encoded><![CDATA[Hey everyone! I've been lurking for a bit while we rolled out CyberArk, and I'm still wrapping my head around all the concepts. Something our security team mentioned early on was the importance of keeping our safe metadata accurate, especially the "managed by" field for owners.

In our world, that ownership info *should* live in our central CMDB. We kept finding mismatches, which was causing confusion during audits. Since I'm more comfortable with scripting than vault diving, I thought I'd try to bridge the gap as a learning project.

I wrote a PowerShell script that uses the CyberArk PAS REST API (which was an adventure to figure out! &#x1f605;). Every night, it:
1. Pulls a list of all safes and their details.
2. Queries our CMDB's API (ServiceNow) for application owner info.
3. Compares the "managed by" field in CyberArk against the CMDB owner.
4. If they differ, it updates the safe in CyberArk and logs the change.

It's been running for a few weeks now and has cleaned up hundreds of stale entries automatically. I was really surprised it worked! I'm sure this is basic stuff for a lot of you, but for me, connecting these two systems felt like a big win.

My main question is: is this a common practice? Are there hidden pitfalls with automating safe metadata updates like this? I'm a little worried about something going wrong in the script and accidentally changing permissions or something it shouldn't. Any advice would be awesome!

Thx!]]></content:encoded>
						                            <category domain="https://communities.stackinsight.net/community/cyber-cyberark/">CyberArk Reviews</category>                        <dc:creator>Emily L</dc:creator>
                        <guid isPermaLink="true">https://communities.stackinsight.net/community/cyber-cyberark/showcase-i-scripted-a-way-to-reconcile-cyberark-safes-with-our-cmdb-nightly/</guid>
                    </item>
				                    <item>
                        <title>Am I the only one who logs more tickets for connector issues than actual threats?</title>
                        <link>https://communities.stackinsight.net/community/cyber-cyberark/am-i-the-only-one-who-logs-more-tickets-for-connector-issues-than-actual-threats/</link>
                        <pubDate>Sun, 27 Sep 2026 09:06:10 +0000</pubDate>
                        <description><![CDATA[Okay, I need to get this off my chest and see if I&#039;m living in a parallel universe or if others are sharing this experience. &#x1f605;

For context, we&#039;ve been using CyberArk for about 18 mo...]]></description>
                        <content:encoded><![CDATA[Okay, I need to get this off my chest and see if I'm living in a parallel universe or if others are sharing this experience. &#x1f605;

For context, we've been using CyberArk for about 18 months now. Our security team loves the vault and the core PAM functionality—it's solid. But my team (I'm in martech, but I get pulled into identity and access stuff because of our automation workflows) spends an *incredible* amount of time dealing with... connectors. Or more specifically, the breakage, the maintenance, and the mysterious "offline" statuses of connectors for various integrated platforms.

It feels like for every one legitimate security event or policy violation we catch, I log three tickets because:

*   A connector for one of our cloud marketing platforms decides to go idle and won't re-authenticate without a full restart.
*   The heartbeat monitoring throws false positives, flooding our alerts.
*   An update on *our* application side (like an API version change) breaks the CyberArk connector, and we're stuck waiting for a patch or a workaround.
*   The logs are sometimes vague—"connection failure"—and the troubleshooting steps are a deep dive that our sysadmins don't always have time for.

I'm all for robust security, truly! And I love comparing features and building detailed workflows (the lead scoring and segmentation enthusiast in me enjoys mapping out access flows). But the operational overhead right now feels skewed. We implemented a PAM solution to reduce risk and streamline credential management, but the "streamline" part gets hung up on these integration hurdles.

Is this just the cost of doing business with a complex enterprise tool? Have others found a way to stabilize this layer? Maybe a specific version improved things? I'd love to compare notes on:

*   Which types of connectors seem most stable vs. which are notoriously fiddly.
*   Your team's structure—do you have dedicated personnel just for connector maintenance?
*   Any monitoring or automation you've built *around* CyberArk to pre-empt these tickets.

Grateful for any shared wisdom or even just solidarity!]]></content:encoded>
						                            <category domain="https://communities.stackinsight.net/community/cyber-cyberark/">CyberArk Reviews</category>                        <dc:creator>elena_g</dc:creator>
                        <guid isPermaLink="true">https://communities.stackinsight.net/community/cyber-cyberark/am-i-the-only-one-who-logs-more-tickets-for-connector-issues-than-actual-threats/</guid>
                    </item>
				                    <item>
                        <title>What&#039;s the best way to start a PoC? Should we focus on servers or people first?</title>
                        <link>https://communities.stackinsight.net/community/cyber-cyberark/whats-the-best-way-to-start-a-poc-should-we-focus-on-servers-or-people-first-2/</link>
                        <pubDate>Fri, 25 Sep 2026 07:45:55 +0000</pubDate>
                        <description><![CDATA[Hey folks, data_shipper_joe here! Normally I&#039;m chatting about syncing data from APIs into warehouses, but I&#039;ve been pulled into our company&#039;s CyberArk PAM evaluation project. Our data pipeli...]]></description>
                        <content:encoded><![CDATA[Hey folks, data_shipper_joe here! Normally I'm chatting about syncing data from APIs into warehouses, but I've been pulled into our company's CyberArk PAM evaluation project. Our data pipelines need secrets, and our app teams need secure server access, so it's time to get serious about PAM.

We're planning a Proof of Concept and hit a classic debate: do we start by vaulting the credentials for our application servers and databases (the "servers" side), or do we begin by managing privileged access for our DevOps and DBA teams (the "people" side)?

From my data integration world, I'm used to tackling the biggest pain point first. For us, that's probably the automated service accounts used by our pipelines. They're currently handled in a... let's say "less than ideal" way. But I've heard that onboarding human users first can build quicker visibility and buy-in.

So, for those who've been through a CyberArk rollout: what was your PoC entry point? Did you start with server credentials to secure the automation layer, or with user sessions (like SSH/RDP) to address immediate human access risks? Any lessons on what made the pilot phase smoother or more successful?

Looking for that practical, "wish I knew this before" advice. Thanks in advance]]></content:encoded>
						                            <category domain="https://communities.stackinsight.net/community/cyber-cyberark/">CyberArk Reviews</category>                        <dc:creator>data_shipper_joe</dc:creator>
                        <guid isPermaLink="true">https://communities.stackinsight.net/community/cyber-cyberark/whats-the-best-way-to-start-a-poc-should-we-focus-on-servers-or-people-first-2/</guid>
                    </item>
				                    <item>
                        <title>Anyone actually using CyberArk in production with AWS Secrets Manager?</title>
                        <link>https://communities.stackinsight.net/community/cyber-cyberark/anyone-actually-using-cyberark-in-production-with-aws-secrets-manager-2/</link>
                        <pubDate>Tue, 25 Aug 2026 05:20:54 +0000</pubDate>
                        <description><![CDATA[Hey everyone! &#x1f44b; I&#039;m just starting my DevOps journey and I&#039;m trying to wrap my head around enterprise secrets management.

My team is discussing a potential move to CyberArk, but we&#039;r...]]></description>
                        <content:encoded><![CDATA[Hey everyone! &#x1f44b; I'm just starting my DevOps journey and I'm trying to wrap my head around enterprise secrets management.

My team is discussing a potential move to CyberArk, but we're heavily invested in AWS. I keep reading that CyberArk can integrate with cloud services, but I haven't found clear, real-world examples.

Is anyone here actually running CyberArk *with* AWS Secrets Manager in production? I'm especially curious about:

*   What does the workflow look like? Does CyberArk become the single source of truth, pushing secrets to Secrets Manager?
*   How do your applications in EC2 or EKS actually retrieve them? Do they talk to CyberArk or to Secrets Manager?
*   Any major pain points or gotchas for this setup?

A simple example of how you've configured this would be amazing for a beginner like me. Thanks so much for any insight you can share!]]></content:encoded>
						                            <category domain="https://communities.stackinsight.net/community/cyber-cyberark/">CyberArk Reviews</category>                        <dc:creator>devops_rookie_2025</dc:creator>
                        <guid isPermaLink="true">https://communities.stackinsight.net/community/cyber-cyberark/anyone-actually-using-cyberark-in-production-with-aws-secrets-manager-2/</guid>
                    </item>
				                    <item>
                        <title>CyberArk review from a 5-person security team - honest take</title>
                        <link>https://communities.stackinsight.net/community/cyber-cyberark/cyberark-review-from-a-5-person-security-team-honest-take-2/</link>
                        <pubDate>Mon, 24 Aug 2026 17:41:00 +0000</pubDate>
                        <description><![CDATA[We were a small team tasked with bringing some order to a chaotic credential situation for a client—database passwords, service accounts, root access for servers, the works. After a bake-off...]]></description>
                        <content:encoded><![CDATA[We were a small team tasked with bringing some order to a chaotic credential situation for a client—database passwords, service accounts, root access for servers, the works. After a bake-off with a couple of other PAM tools, we went with CyberArk. We managed the rollout and have been living with it for about 18 months now.

Here's our honest take from a small-team, hands-on perspective:

**The Good:**
*   **It's the gold standard for a reason.** Once it's in, it's incredibly robust. The security model is comprehensive, and the vaulting is rock-solid. For high-privilege accounts in regulated environments, it's hard to beat.
*   **The heartbeat feature is a lifesaver.** Automatic password rotation for service accounts eliminated a huge manual burden and a major security gap. This alone justified a big part of the cost.
*   **Detailed session monitoring and recording** provided the audit trail our client desperately needed for compliance. The peace of mind here is real.

**The Not-So-Good:**
*   **The learning curve is steep.** It's a complex enterprise suite, not a simple SaaS tool. For a team of five, becoming proficient felt like getting another certification. The initial setup and policy configuration were not trivial.
*   **Cost is a major factor.** The licensing is significant, and the operational overhead (management, upkeep) for a small team is non-trivial. You need to have a clear, high-value use case to make the ROI work.
*   **It can feel heavy.** For simpler use cases like shared team passwords for a marketing SaaS tool, it's complete overkill. We ended up using a lighter, separate tool for those scenarios.

**Bottom line:** If you need industrial-strength privilege access management for critical systems and are prepared for the operational commitment, CyberArk delivers. For smaller teams or less critical secrets, the complexity and cost might be overwhelming. It's a powerful engine, but you don't always need a semi-truck to go to the grocery store.

Would be curious to hear how other small teams have handled the operational load.

-mike]]></content:encoded>
						                            <category domain="https://communities.stackinsight.net/community/cyber-cyberark/">CyberArk Reviews</category>                        <dc:creator>Mike C.</dc:creator>
                        <guid isPermaLink="true">https://communities.stackinsight.net/community/cyber-cyberark/cyberark-review-from-a-5-person-security-team-honest-take-2/</guid>
                    </item>
				                    <item>
                        <title>Switched from manual spreadsheets to CyberArk, here are the pain points we hit.</title>
                        <link>https://communities.stackinsight.net/community/cyber-cyberark/switched-from-manual-spreadsheets-to-cyberark-here-are-the-pain-points-we-hit/</link>
                        <pubDate>Sun, 23 Aug 2026 07:40:49 +0000</pubDate>
                        <description><![CDATA[We finally moved our password management from messy spreadsheets to CyberArk last quarter. It was a big step for our small team, but the setup wasn&#039;t as smooth as I hoped.

The biggest pain ...]]></description>
                        <content:encoded><![CDATA[We finally moved our password management from messy spreadsheets to CyberArk last quarter. It was a big step for our small team, but the setup wasn't as smooth as I hoped.

The biggest pain point was the initial policy configuration. The defaults were too restrictive for our devs right away, causing access denials during testing. We also underestimated the time needed to onboard all our service accounts. The learning curve for just basic daily operations felt steeper than expected. Has anyone else faced similar issues when starting out? What helped you get past the initial hump?]]></content:encoded>
						                            <category domain="https://communities.stackinsight.net/community/cyber-cyberark/">CyberArk Reviews</category>                        <dc:creator>cloud_infra_rookie</dc:creator>
                        <guid isPermaLink="true">https://communities.stackinsight.net/community/cyber-cyberark/switched-from-manual-spreadsheets-to-cyberark-here-are-the-pain-points-we-hit/</guid>
                    </item>
				                    <item>
                        <title>How-to: Automate onboarding of new service accounts using Ansible and the CLI.</title>
                        <link>https://communities.stackinsight.net/community/cyber-cyberark/how-to-automate-onboarding-of-new-service-accounts-using-ansible-and-the-cli-2/</link>
                        <pubDate>Fri, 21 Aug 2026 21:41:02 +0000</pubDate>
                        <description><![CDATA[We often discuss CyberArk&#039;s web UI and REST API, but the PACLI (and now the OPA-CLI) remains a powerful, scriptable workhorse for many on-premises environments. A common operational hurdle i...]]></description>
                        <content:encoded><![CDATA[We often discuss CyberArk's web UI and REST API, but the PACLI (and now the OPA-CLI) remains a powerful, scriptable workhorse for many on-premises environments. A common operational hurdle is the manual onboarding of new service accounts, especially during large-scale application deployments. This process can be streamlined significantly by combining Ansible for orchestration and the CyberArk CLI for execution.

Here’s a proven, high-level approach we've implemented for several clients to automate this. The core idea is to use Ansible to gather required account details, format them for the CLI, and handle the secure session lifecycle.

*   **Prerequisites &amp; Safety First:** Ensure your Ansible control node has the PACLI/OPA-CLI installed and configured for a specific, dedicated safe. The user associated with the CLI session should only have permissions necessary for adding accounts to that safe. Never store privileged credentials in plain text within playbooks; use Ansible Vault or a similar secrets manager for the CLI user's credentials.

*   **The Ansible Playbook Workflow:**
    *   Define a list of target systems and service accounts as structured data (e.g., in a variable file or prompted input).
    *   For each account, the playbook should:
        1.  Initiate a PACLI/OPA-CLI session using the secured credentials.
        2.  Execute a sequence of CLI commands to create the account object within the designated safe. This typically involves setting the `Address`, `UserName`, and `Password` parameters.
        3.  Immediately trigger a CPM change to set a managed, complex password.
        4.  Log the outcome and close the session.

*   **Key Considerations &amp; Pitfalls:**
    *   **Idempotency:** Your script should check if an account already exists in the safe before attempting to create it, to avoid errors.
    *   **Error Handling:** Build in robust checks for each CLI step. If the account creation fails, the playbook should fail gracefully and report why.
    *   **Logging:** Maintain detailed logs of all actions for audit trails. The CLI's own log should be supplemented by Ansible's task output.
    *   **Platform Details:** Remember to populate platform-specific properties if your CPM policies require them. This often gets missed in automation, leading to accounts the CPM cannot manage.

This method moves onboarding from a manual, ticket-driven task to a self-service or deployment-integrated step. It enforces consistency and drastically reduces the time from request to a fully managed privileged account. I'm interested to hear if others have built similar automation and what specific challenges you faced—particularly around handling different account platforms or integrating with service catalogs.]]></content:encoded>
						                            <category domain="https://communities.stackinsight.net/community/cyber-cyberark/">CyberArk Reviews</category>                        <dc:creator>Consultant Mark</dc:creator>
                        <guid isPermaLink="true">https://communities.stackinsight.net/community/cyber-cyberark/how-to-automate-onboarding-of-new-service-accounts-using-ansible-and-the-cli-2/</guid>
                    </item>
				                    <item>
                        <title>Why is CyberArk so hard to manage for small teams?</title>
                        <link>https://communities.stackinsight.net/community/cyber-cyberark/why-is-cyberark-so-hard-to-manage-for-small-teams-2/</link>
                        <pubDate>Fri, 21 Aug 2026 19:31:00 +0000</pubDate>
                        <description><![CDATA[Let&#039;s be honest, CyberArk was built for a specific kind of customer: the massive enterprise with a dedicated security engineering unit and a compliance team breathing down their neck. It&#039;s t...]]></description>
                        <content:encoded><![CDATA[Let's be honest, CyberArk was built for a specific kind of customer: the massive enterprise with a dedicated security engineering unit and a compliance team breathing down their neck. It's the ultimate fortress, but for a small team, you're not just living in it—you're also the sole architect, mason, and janitor.

The complexity isn't an accident; it's the product. You're not just managing passwords. You're managing a proprietary Windows service architecture, a bespoke database schema, and a policy engine that seems to require a CyberArk-certified scholar to interpret. Need to troubleshoot why a simple account rotation failed? Good luck navigating the labyrinth of PVWA logs, CPM logs, and PSM logs—each with its own cryptic format. The "out of the box" experience feels more like "out of the crate, now assemble the engine yourself."

Then there's the operational overhead. The principle of least privilege is great until you have to manually define and maintain it for every single safe, platform, and user. In a small team, the person who configures the intricate Access Control is likely the same person who needs emergency access at 2 a.m., creating a conflict the system wasn't designed for. It's a full-time job just to keep the vault running, never mind actually using it effectively.

I'm all for robust security, but when a tool demands more hours to administer than the number of secrets it protects, you have to question the ROI. For small teams, the sheer weight of the platform often forces dangerous shortcuts—like over-provisioning access or delaying critical updates—which defeats the entire purpose. Isn't the goal to reduce risk, not create a new category of operational risk?

—Greg]]></content:encoded>
						                            <category domain="https://communities.stackinsight.net/community/cyber-cyberark/">CyberArk Reviews</category>                        <dc:creator>gregm</dc:creator>
                        <guid isPermaLink="true">https://communities.stackinsight.net/community/cyber-cyberark/why-is-cyberark-so-hard-to-manage-for-small-teams-2/</guid>
                    </item>
				                    <item>
                        <title>Has anyone benchmarked the performance hit of PSM proxy on high-traffic SQL?</title>
                        <link>https://communities.stackinsight.net/community/cyber-cyberark/has-anyone-benchmarked-the-performance-hit-of-psm-proxy-on-high-traffic-sql-2/</link>
                        <pubDate>Fri, 21 Aug 2026 15:01:12 +0000</pubDate>
                        <description><![CDATA[Hey everyone! &#x1f44b;

I&#039;ve been diving deep into our CyberArk PSM setup for database access, and while the security benefits are a no-brainer, I keep circling back to a performance questi...]]></description>
                        <content:encoded><![CDATA[Hey everyone! &#x1f44b;

I've been diving deep into our CyberArk PSM setup for database access, and while the security benefits are a no-brainer, I keep circling back to a performance question we haven't fully answered. We have a handful of business-critical, high-traffic SQL Servers (think thousands of queries per minute, some quite complex) that our analysts need to access via PSM. We're using the standard RDP proxy connection to a dedicated PSM server, which then connects to the target DBMS via SSMS.

Lately, I've been hearing some grumbling from our power users about "lag" or "feeling slower" when running large reports through the PSM session compared to their old, direct (and now forbidden!) connections. It's not quantified—just a feeling. But in my world, feelings are just unmeasured metrics! &#x1f604;

So, I'm on a mission to benchmark this properly. Before I reinvent the wheel, I wanted to ask:

**Has anyone here done a formal performance comparison for SQL workloads over PSM proxy vs. direct?**

I'm especially curious about:

*   **Methodology:** What did you measure? Average query execution time reported by SQL Server? End-to-end latency from the user's click to data appearing? Network latency *through* the proxy? All of the above?
*   **Findings:** What was the average overhead or "performance hit" percentage you observed? Was it negligible (10%)? Did it vary dramatically based on result set size or query complexity?
*   **Configuration Tweaks:** Did you find any PSM or connection broker settings that helped mitigate latency? For instance, anything around session timeouts, RDP optimization settings, or resource allocation on the PSM servers themselves?
*   **Scale Context:** How many concurrent PSM sessions were hitting your SQL boxes during your tests? Our peak could be 30-40 concurrent sessions on a single target.

I'm planning to set up a controlled test using a repeatable set of stored procedures (some simple selects, some heavier joins and aggregates) and capture timestamps at various points. But if someone has a script or a report template they'd be willing to share, I'd be eternally grateful! It would save me so much time.

Also, if your conclusion was "the hit is real, and here's how we justified it to the business," I'd love to hear that story too. Balancing security and performance is always the fun part, right?

Thanks in advance for any data, war stories, or config wisdom you can offer!]]></content:encoded>
						                            <category domain="https://communities.stackinsight.net/community/cyber-cyberark/">CyberArk Reviews</category>                        <dc:creator>elena_g</dc:creator>
                        <guid isPermaLink="true">https://communities.stackinsight.net/community/cyber-cyberark/has-anyone-benchmarked-the-performance-hit-of-psm-proxy-on-high-traffic-sql-2/</guid>
                    </item>
				                    <item>
                        <title>Help: Our auditors say session recordings aren&#039;t immutable. How to prove they are?</title>
                        <link>https://communities.stackinsight.net/community/cyber-cyberark/help-our-auditors-say-session-recordings-arent-immutable-how-to-prove-they-are-2/</link>
                        <pubDate>Tue, 18 Aug 2026 19:30:59 +0000</pubDate>
                        <description><![CDATA[Hi everyone. I&#039;m evaluating CyberArk&#039;s Privileged Access Manager (on-prem) for my organization, and we&#039;ve hit a snag during an internal audit. The auditors are questioning the immutability o...]]></description>
                        <content:encoded><![CDATA[Hi everyone. I'm evaluating CyberArk's Privileged Access Manager (on-prem) for my organization, and we've hit a snag during an internal audit. The auditors are questioning the immutability of our session recordings. Their point is that if we have administrative access to the vault and backend, what technically prevents alteration or deletion? They want concrete evidence, not just a vendor assurance.

I need to understand how others have successfully demonstrated this for compliance (like SOX, PCI-DSS). I've read the documentation on tamper-proof storage, but I need real-world implementation details.

Specifically:
*   What exact logs, configuration settings, or system-generated proofs do you provide to auditors? For example, are there specific hash chains or write-once-read-many (WORM) storage integrations you point to?
*   How does CyberArk's approach compare to other PAM solutions you've seen (like BeyondTrust or Thycotic) on this specific point? Is the verification process more integrated?
*   Has anyone used the CyberArk components (like the Password Vault Web Access or the PrivateArk client) to generate an audit trail that *independently* validates the recording's integrity from access to playback?

Our setup is fairly standard: a vault, a couple of PVWAs, and session monitoring configured for critical servers. Any insights on the specific workflow or even CLI commands you've used to extract this evidence would be very helpful.]]></content:encoded>
						                            <category domain="https://communities.stackinsight.net/community/cyber-cyberark/">CyberArk Reviews</category>                        <dc:creator>eval_engineer_101</dc:creator>
                        <guid isPermaLink="true">https://communities.stackinsight.net/community/cyber-cyberark/help-our-auditors-say-session-recordings-arent-immutable-how-to-prove-they-are-2/</guid>
                    </item>
							        </channel>
        </rss>
		