Official: Shield and Security Center

Got a Workaround: To bypass the AppExchange login flow, log into the target org first in the same browser, then paste the URL into the address bar. Because you authenticate directly to your own org here, this path skips the AppExchange/Trailblazer OAuth handshake entirely, which is what was throwing the invalid_social_token error.

Production:

https://login.salesforce.com/packaging/installPackage.apexp?p0=04tal00000738jNAAQ

Sandbox:

https://test.salesforce.com/packaging/installPackage.apexp?p0=04tal00000738jNAAQ

As the error message suggests, this is a permissions issue with the user authorized in the TSP_Accelerator Named Credential. I'd recommend reviewing that user's profile and permission sets to ensure they have the permissions needed to create Transaction Security Policies. As mentioned here https://help.salesforce.com/s/articleView?id=005321565&type=1, there is a new permission "Modify Transaction Security Policy" that is required to create, update, delete, enable, or disable TSPs. This new permission is now included in the TSP Accelerator Permission Set that is included with the package.

Salesforce did create a couple help pages as follow ups to these questions.  The first link below summarizes all the June changes.  The second link is specific to the Phishing resistant MFA stuff.  These were posted May 5 and May 6 respectively.   

June overview  

Phishing resistant MFA 

Following up on this thread from a long time ago- Data Detect has since evolved and it's now part of the Shield app since Sept last year. It requires no installation and just needs assignment of a user permission. It currently supports scanning upto 100 objects (all fields) in a single scan which is set to increase dramatically in upcoming releases. There is no performance impact of this scan and provides you with ALL the results of the scan vs only 50 results per field in the Data Detect managed package. Scheduled scans are coming soon too! 

Storage Impact: 

Event Monitoring storage is "free"/included.  However, several of the TSPs function by using a custom object where a record is created for every event that comes in.  While events did not have an impact on platform storage previously, now they do.  Some of the events being monitored are high-volume in some orgs, and the impact to storage could be meaningful. 

The potential storage impact isn't highlighted in the User Guide at all, and the only mention I see is when activating certain TSPs an optional last step that is given (which is manual): 

"Optional: Activate the TSP - Delete Record Access Records Flow to delete unnecessary Record Access records" 

Thank you for delivering a record cleanup process, but the importance of this flow and the potential storage impact seems like something documentation should stress more.

Hi @Mona Verma - glad that you have access to the blog & documentation for this feature. 

Let's walk through the high-risk metrics and what to watch for with each: 

1. Guest Aura Requests — Indicates that guest users are invoking Aura requests on a public site. This can be normal behavior, but it can also signal malicious activity. The recommended action is to ensure the principle of least privilege is applied when exposing data to the public internet. See this blog for details. 

2. Deactivated User Login Attempts — A deactivated user is attempting to log into your Salesforce org. This could be a terminated employee trying to regain access, or simply an accident. Depending on context, the right response may be a direct conversation with the person involved. 

3. Anonymous Apex Execution — A frequently requested metric for orgs that want visibility into whether developers are executing code anonymously for potentially malicious purposes, such as exporting data. Reviewing the execution details can help you determine whether a specific run involved suspicious activity. 

4. Insufficient Access — Someone attempted to access data they don't have permission to view. This could be as simple as a user copy-pasting a record ID into the URL bar, or it could reflect a legitimate workflow being blocked by a misconfigured permission. Either way, it's worth reviewing with the user to either address the suspicious behavior or correct the access issue. 

5. Triggered Transaction Security Policies — A transaction security policy created by an admin was triggered. This is worth reviewing to understand who triggered it, whether it was a one-time occurrence, and whether there's a pattern of behavior that may indicate policy violations. It can help you identify users who are either unaware of company policies or actively attempting to exfiltrate data. 

I hope this helps! Let me know if there is anything else I can assist with