Most namespace parsers call ConfigUtils.registerProviderManagerIfNecessary() if they configure beans that require access to an authentication manager. However, GlobalMethodSecurityBeanDefinitionParser doesn't do this, which may result in exceptions when loading the Spring context.
One use case where this happens is when using hierarchical contexts, where most security configuration (like HTTP filters and such) is done in the (child) web application context, and you want to use the sec:global-method-security element (using a default authentication manager) in some parent context. In this case, a default (or custom) authentication manager is only registered in the child context, to which the parent context doesn't have access.
In general, I also think that the provider manager should be configurable on all namespace elements that require an authentication manager. This would allow to share a single authentication manager (defined in the most upper context) from multiple child contexts, for example for authentication purposes from multiple web applications in a single ear, or for (re-)authentication purposes from AbstractSecurityInterceptor.
Finally, I never really understood why an authentication manager is always required in authorization-related classes (e.g. AbstractSecurityInterceptor). This is only required if alwaysReauthenticate==true or if the authentication object is not yet authenticated. If you don't use these features (I've never seen use for them in a pre-authenticated scenario), then it makes no sense to require an authentication manager. Making the authentication manager optional would greatly simplify dependency management, especially in the case of hierarchical contexts.