To start with, the name is objectively “wrong” and it fails to address the problem stated above. I imagine that this has already gone through a bunch of committees and it will be impossible to change, but…
What does a new customer think “Architected for Atlassian” is supposed to mean? At face value, it does not imply anything about security or trust. If an app does not have the A4A badge, but it was still built from the ground up for Atlassian, does that mean it was not “architected” for Atlassian, even though it was?
“Architected” is not a good word for this program and it creates more confusion than it solves. If your goal is to make things clearer for the customer, this needs a better name. A security-focused name, or even reusing one of the old program names, would be a better choice.
This should not be present in the current version of A4A. Atlassian is unnecessarily mixing its definitions of security posture with different, organizational goals to move people off Connect, when these two are not related.
Connect is officially and fully supported through the end of 2026, so this should not be a current criterion for A4A, full stop.
Even if you want to modify the A4A criteria for 2027+, remember that even after Connect reaches EOS, Atlassian has defined EOS as meaning that “only critical or security-related bugs will be addressed”. Security-related bugs will be addressed, so I still do not understand what security or trust problems this would present.
If Atlassian is trying to use this as a motivational factor to get vendors to move to Forge, this also misses the mark (and is also irrelevant to security and trust). Some vendors are being effectively held hostage to Atlassian’s delivery schedule of Forge modules, and if those modules are not delivered on time, vendors have no choice but to remain on Connect.
The current Forge/Connect implementation almost requires the use of undocumented endpoints. Can you provide an escalation path to make some of these endpoints officially documented?
This should not be a criterion. No Forge app can meet this requirement because Atlassian strips rate-limiting headers delivered to Forge app front ends (ECO-899, FRGE-1923).
This should be removed, because Atlassian has made it impossible for apps to “degrade gracefully” with the new rate-limiting implementation. Atlassian is planning to enforce new rate limits which reset only once per hour. If the rate limit is inadvertently breached, there is no way to “gracefully” tell users that they cannot use the app for an hour’s time. The proposed rate-limiting headers are not even available on the front end, and even if they were, insufficient information is provided and it is not possible for apps to proactively prevent all rate limit breaches. The spec linked above says:
This should be clarified to indicate that apps are also eligible if they store data only within the host product.
I also do not see why this should be present. This is again conflating Atlassian organizational goals with the security/trust posture. At first glance, this has nothing to do with trust or security. Certain apps may have good reasons for having manual migration processes.