It looks like a responsiveness failure to me.
The result appears like a technical glitch - which it is, on the device surface - but the first step toward a fix may lie in more explicit UI spec instructions on dev implementation, which I'll get to.
An iframe is essentially a window to some other content embedded within a window.
A good and frequently used example is the (usually small until expanded) map view within applications like Yelp, OpenTable (gastronomy) or Strava, Fitbit (sports), or even Uber, where the map that shows you nearby available rides is critical.
These maps are typically fed by an external service from Google or Apple (you can typically tell by their graphics), which is why you need to tell you device to "allow tracking my location" or so. Because the apps I mention need to display other dashboard style information alongside the map content, their UI designers will assign a carefully calibrated size (W and H) and location (X and Y) to the iframe 'hosting' the map. This is strictly all that's required. The iframe becomes a portal to the portion of the map of interest to the app's purpose (with the surroundings acting as 'mask'), but within the iframe you can usually pan, zoom and scroll. And, of course, toggle the map to full-screen view and back.
In-frame scrolling is standard behaviour of iframes - it should not have to be enabled as such.
Iframes are typically implemented responsively - provided the front end is done well: As the iframe loads it 'asks' the target device How tall and wide are you? and adjusts its size and location accordingly. Perhaps width is not defined in absolute pixels but by equal left and right padding, presenting you a proportionately wider portal on a larger device. Or at a more abstract level by sticking to a column layout. This is essentially what you describe; however I'm not sure these rules were actually heeded. A few well-placed nagging questions may shed some light on that matter.
https://material.io/design/layout/responsive-layout-grid.html#
If an iframe was dimensioned in absolute terms, and those absolute terms were based on a larger device, perhaps even desktop browser window, it will anchor its top left corner to the specified X and Y positions on a smaller screen, but overshoot the available display zone towards the right and bottom, rather than adapting.
Failing all other approaches you could handle this by an explicit instruction above the iframe to use gestures to pan or zoom to the desired content (if those gestures are recognised) but needless to say that is extremely poor UX, which to me calls the whole business model of using a third-party offering via iframe into question.
Make the product manager / owner your ally - trust me, I recognise push-back situations like that from a distance! A third-party iframe, if that's the way to go, has.to.work flawlessly.
Now, in terms of due diligence, be sure to include explicit specs in your UI documentation or comp - or ask the UI designer you collaborate with to do so if this isn't your core responsibility - to heed responsive or adaptive iframe sizing. You can always add a few concrete examples by researching the smallest and largest of the most common smartphone and tablet screens - iPhone, Samsung, etc. - and make a visual representation of the problem. Essentially, and this is essential to push-back politics that must not tailspin into blame storming: We as designers need to articulate in our specs to the developers which undesired UI effects must not occur, i.e. iframes with 'blind zones' as per your example above. The onus is squarely on the developer to figure out how to build it. Your UI spec may need to be more explicit in terms of iframe behaviour rules - and that will help convey to the technical team that you mean business. Dev's, in my repeated experience, do respond well to design intent presented with purpose and precision.
Your case is further complicated, of course, by not being a map, which you can zoom and scale freely, but a canned third-party form of a given (and likely fixed) size. Do you know what that size is - esp. its width? With that, you might be able to devise scaling rules in your spec. Let's say you find that the rightmost 15% get cut off on most devices. In that event you could ask the devs to put in a scale factor expressed as a percentage, until the form fits full-width without lateral scrolling. It's hard for a forum audience to pursue this further without more detail on the specific content. Good luck!
