The problem at hand does not seem to be a question of correct asterisk marking rules, or a literal interpretation of metaphor behind the radio button control.
Rather, the conflict from your description appears to be this:
While the two radio button selection instances are marked as required, the requirement is already fulfilled by pre-populated selection. However the true requirement seems to me that your user should make a meaningful choice, not just any.
So let's first ensure that that actually happens, and then think about appropriate UI presentation.
Pre-populated but required selections can be problematic because a momentarily inattentive user may consent to 'canned' choices that aren't what they would actually choose. The design problem is less a case of "You must make any old choice in order to proceed", and conformity with hard conventions for required selections, but more of "Make sure the radio button selection we pre-populated for your convenience is actually what you wish".
Yes, the asterisk to indicate required is technically redundant, as others have written. But if it is critical that your users provide accurate information on this page (and that's what required implies), present all choices in an indeterminate start state, including radio buttons. Do not pre-populate anything.
That would ensure that as your first-time user encounters the set of forms each and every one must be filled, checked, and selected ("signed, sealed, delivered...") before the calls to action 'Cancel' and 'Save' become available to them.
It is perfectly okay to my mind to present a set of radio button type controls in an initial none-selected state, even though the physical metaphor of radio button controls implies a type of 'whack-a-mole' behaviour ('one pops in, all other ones pop out' kind of thing). But remember that this is just a metaphor. If you're working within a development kit of sorts, or even a prototype application like Axure RP, UI controls like that usually come as a library 'widget' with black-box behaviour at first. That is an unfortunate constraint, but more often than not it can be overridden. If you have some progressive disclosure going on - i.e. a set of choices presented further down-page depend on an earlier radio button setting, you could even add a 'clear' function to return the radio button set to a nil state.
Looking at your UI example, it occurs to me that all forms are mandatory.
The effect of marking them as such repeatedly (*) gets washed out because the constraint seems universal to all of them - unless your actual form is longer and you're just presenting an excerpt for simplicity, or the form consists of several further pages on which compulsory selections are interspersed with optional ones.
I would therefore guard-rail the user by two things:
A collective headline sub-caption "All selections are required". If all selections are truly required, say so in no uncertain terms.
Disable 'Save', until all selections have been made, up to the very last one. Keep 'Cancel' active; this is how your user can safely exit the form.
By the above an explicit verbal instruction tells your user why the calls to action are blocked. If in addition, present all possible selections initially in an indeterminate state and thus force your user - appropriately - to provide the necessary information with intent and purpose, rather than have them inadvertently accept canned selections in auto-pilot mode.
Note I said initially. The above describes the carte-blanche state in which a first time user should find the form. If there is a function by which the user can instruct the application to remember my settings, all selections become sticky and can be edited (as needed, or simply left as they are) on subsequent visits.
I hope that helps. Best of success!